Publish a required Qodo status instead of parsing comments

[deonmenezes]

Raised from Qodo's review of #14, which proposed this as the better architecture and was right.

Today

.github/workflows/qodo-automerge.yml reads Qodo's verdict out of an issue comment, because Qodo publishes no check run, no commit status and no approving review. Verified on #13:

pulls/13/reviews                 -> []
commits/$SHA/status  .statuses   -> []
commits/$SHA/check-runs          -> only macroscopeapp

So the workflow both translates the verdict and executes the merge.

Why that's worse than it needs to be

Qodo's own review put it plainly: publishing a synthetic required status would keep GitHub responsible for enforcing merge eligibility, and separate verdict translation from merge execution. Concretely, today's design means:

• the merge rule lives in a workflow rather than in branch protection, so it can be bypassed by anyone who can push a workflow change
• correctness depends on parsing a human-readable comment, which is why Merge on a clean Qodo review #14 needed four fixes and Trigger on edited comments, or the gate never sees a verdict #16 needed a fifth
• there's no visible per-commit signal of the review outcome in the GitHub UI

Proposed

1. A workflow that consumes the Qodo comment and publishes a commit status (e.g. qodo/review) as success or failure against the reviewed SHA.
2. Branch protection on main requiring qodo/review plus build.
3. Delete the merge step. GitHub merges via native auto-merge once the required statuses are green.

Leaves the parsing problem intact but shrinks its blast radius: a parser bug then fails to publish a status rather than performing an unreviewed merge.

Not done because

It needs branch protection configured on the repository, which is a change with consequences beyond this workflow. Recorded rather than silently skipped.

Co-Authored-By: qodo-code-review[bot] <151058649+qodo-code-review[bot]@users.noreply.github.com>