The PR reviewer can't be the one who wrote it
Agents open PRs as drafts and mark them ready on their own. One agent reviews, and the merge stays with me. What broke before this worked.
My agents (programs set up to carry out tasks) open PRs (requests to review and include
code changes). Each task gets a worktree (a separate copy of the project files) from
the develop branch (a separate line of work). The PR starts as a draft.
Only the person who did the work decides when it is ready. Then SENTINEL steps in as
the only agent allowed to review. I handle the merge (add the changes to the project).
Here is what broke before this worked.
Draft and ready
Draft means the author is still working. Ready means the request has been sent for review. SENTINEL does not review drafts. So the PR state already shows who needs to act.
The mistake was mine. The agents finished the work, checked it, and asked whether they could mark the PR ready. That left me deciding something I do not need to decide. I authorize the merge, not the review request. Now the author agent marks the PR ready after the work is done and checked. It does not need to ask. Asking only delays the PR.
One reviewer, one SHA
SENTINEL has three modes. Lite makes the first review of changes up to 150 effective lines. Delta makes a second review after a prior decision I trust. Full is for the other cases. There is one reviewer of record. Two agents cannot each assume the other checked the same PR.
The verdict includes Reviewed-Head-SHA (the identifier of the exact code version
that was read). This matters because approval only applies to that version. For me, done means
approved on the current version, with automatic checks passing on that same version. If
someone sends another code version after the verdict, the approval no longer counts. Without
that reference, someone could approve, add one more change, and merge code nobody
reviewed.
On August 4, ADR-020 (a record of a decision about how the system is built) recorded that SENTINEL got its own review identity on GitHub. If the reviewer posts as the author, it looks like the author approved their own work. Setting up that identity had one problem. Digital credentials with specific permissions returned 404 (resource not found) on private repositories when the account was only a collaborator. That shaped how I configured the identity.
Evidence in the PR body
On August 12, a vault PR got the CHANGES_REQUESTED status (changes requested) twice
for the same reason. I had put all
the evidence in a comment. The reviewer reads the PR body, not the comment. I lost two
rounds because the proof was in the wrong place. Evidence goes in the PR body.
Who actually merges
On September 5, I measured who was doing the merges. Over 30 days, 30 out of every 100 merges in the assistant's repository had my name. In the ops repository, it was 2 out of 100.
Measured on September 5. Some of the merges with my name were done by agents using my credentials.
Show data
| Assistant repository | 30 of 100 |
|---|---|
| Ops repository | 2 of 100 |
Not all merges with my name were mine. Some agents used my credentials. The name in the record did not show who pressed the button. Now a protection blocks the agents, and I do the merge.
Merge commits and authors off the list
The rule is to use merge commit. It records the joining of two lines of work. Never use squash, which combines the changes into one record. Squash broke comparisons of the changes.
On September 6, I found that the automatic review process skipped PRs from authors outside its approved list. A PR opened by a second bot account got no review. The records also did not say why.