Coroid makes many decisions while it carries a piece of work: whether a request should become work at all, how to build it, and whether the result is good enough to show you. A few decisions never leave people's hands. Merging is the clearest of them.
Decisions Coroid makes
- Whether a request becomes work. Qualification checks for duplicates, things already fixed and things it cannot reproduce. For requests that arrive without a person, admission then decides under your mandates whether the work may start now, later or not at all.
- How the work is built and verified. The plan, the code, the tests, the quality gates, QA and the review pass. See How Coroid verifies its own work.
- What it would have done about the merge. Coroid records a judgement on every pull request it reviews, and does nothing with it. See How Coroid checks its own judgement.
Decisions that stay with people
| Decision | Who makes it |
|---|---|
| Merge a pull request into your branch | A person, in GitHub or GitLab, or with Approve & merge in Coroid |
| Release and deploy | A person, through your pipeline or a release in Coroid |
| Say what unattended work is for, and its budget | An owner or admin, by publishing a mandate |
| Say what done means for a piece of work | The person who asked for it, in its outcome contract |
| Create work Qualification stopped | A person with permission, with Create work anyway and a reason |
Coroid never merges on its own, and there is no setting that makes it. See Merging.
Mandates do not change who merges
A mandate lets work start without someone asking for each piece. It does not let the result land without someone deciding. Work admitted under a mandate goes through the same verification as any other task and ends the same way: a pull request that waits for a person.
What a mandate adds is accountability for unattended work: which projects it may touch, how much it may spend, and a record of every decision about it.
How Coroid checks its own judgement
For every pull request Coroid reviews, and every task that becomes ready to merge, Coroid writes down what it would have decided if it were allowed to merge:
- Would approve. Everything it needs is in and green: the quality checks on the pull request's latest commit, Coroid's review, your provider's checks, a clean merge and, for a task, its QA and reviewer verdicts.
- Would block. At least one of those blocks.
- Could not tell. Something it needs was missing. Missing evidence never counts as approval.
The judgement is never posted to the pull request, never changes a task and never merges anything. It is not shown in Coroid yet.
Coroid then compares each judgement with what happened after the merge:
- a later pull request titled Revert … marks the earlier one as reverted;
- a later pull request that says Fixes #n marks pull request n as hotfixed;
- on the task's review screen, under What happened after the merge, anyone in the organization can mark a merged pull request as reverted, hotfixed or defect reported.
An approval on a pull request that was later reverted or fixed counts as a wrong approval. On its own repository, Coroid also feeds the same judgement deliberately broken copies of real changes, to measure what it catches.
Why keep this record
So that the question "could Coroid be trusted to merge this kind of change?" is answered with evidence — how often its approvals turned out wrong, for which kinds of change, over how many examples — rather than with confidence. Today nothing acts on the record. If that ever changes, it would be a choice an owner makes explicitly, and this record is what that choice would rest on.