feat: add the reviewer registry that makes the triage queue answerable

[mlorentedev]

Closes #403.

The problem

$ dotf pr triage-queue
pr triage-queue: read reviewer registry: open harness/review-attestation.json: no such file or directory
$ echo $?
1

That command exits non-zero for two different reasons — work is pending, or the question could not be answered — deliberately, so an unanswerable queue is never mistaken for a clear one. Here it was always the second. The consequence: hive could produce no queue-clear evidence for any PR, ever, so every PR closed with the Definition of Done's evidence item skipped rather than met.

The non-obvious part: which marker identifies a review

This is not a copy of the dotfiles registry, and the reason is worth reading before reviewing the file.

CodeRabbit files proper reviews through the reviews API on this repo. Measured on #401: a 5-finding review reading **Actionable comments posted: 5**, sitting in reviews[]. But the queue reads gh pr list --json comments, which returns issue comments only and never reviews[]. Matching the review's own text would have left the queue permanently empty on a repository that is actively being reviewed — the exact false clear the mechanism exists to prevent.

So the registered marker is the walkthrough comment CodeRabbit posts alongside every review, which is comment-shaped. Verified present on both PRs open at the time of writing:

PR	Walkthrough marker	Rate-limit marker	What it was
#401	✅	—	a real 5-finding review
#406	✅	✅	a decline

The limitation this leaves is stated in the file, not left to be rediscovered: the walkthrough is edited rather than reposted on re-review, and createdAt does not move on an edit — so a second review after a push may not re-open the queue for a PR already triaged once. The queue is a floor, not a ceiling. Closing that needs a consumer that reads reviews[], which is a change to the dotfiles CLI, not to this file.

advisory: true, measured here rather than inherited

On #405 and #406, CodeRabbit was rate limited, posted "Review limit reached", and its commit status read success. A green check that means no review ran is precisely the failure this whole mechanism exists to catch. Advisory means its decline does not refuse the change — a quota is a billing state of a third party, not a property of the diff — while its review still attests.

Note what the two settings do together, and it is intended: the decline notice also carries the walkthrough marker, so a rate-limited PR reads as output awaiting disposition rather than as a clear queue. That is the honest answer.

Deliberately absent

The escape and exempt blocks dotfiles carries. Those are read by its review-attestation CI gate, which hive does not run — prtriage reads reviewers and triage.marker and nothing else. A registry declaring policy no consumer here enforces is drift with extra steps. The practical consequence: release-please PRs are not exempted and will queue for a one-line disposition.

Verified end to end

$ dotf pr triage-queue
1 pull request(s) awaiting a disposition:

  #405   chore(master): release 4.1.1
         coderabbitai reviewed, never triaged, 2026-08-24 20:47

Both directions confirmed: #406 correctly omitted (it carries a ## Review triage comment) and #405 correctly surfaced (it does not). The queue found a real open PR I did not know existed.

AGENTS.md gains two bullets in the PR workflow section: how to run the queue and where to record the disposition, and the warning that CodeRabbit's green status can mean it never reviewed.

[coderabbitai]

Warning

Review limit reached

Next included review available in 26 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 63202e68-df10-4440-bc39-984e82b50153

📥 Commits

Reviewing files that changed from the base of the PR and between 66dbf17 and a8f2b6c.

📒 Files selected for processing (2)

• AGENTS.md
• harness/review-attestation.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[mlorentedev]

Review triage

CI: all 7 check runs green (check 3.12/3.13, cross_worker_lock ubuntu + windows, docker, GitGuardian, add-to-project).

Review: none ran. CodeRabbit's commit status reads success; its comment is "Review limit reached". Third PR in a row today with that pattern (#405, #406, this one), which is the measurement behind this PR's own advisory: true setting. This PR is unreviewed.

There is a circularity worth naming rather than glossing: the change that teaches this repo not to trust CodeRabbit's green status is itself merging on an unreviewed green status. That is not a reason to hold it — it is the argument for it — but it does mean the registry lands without an independent read of its marker choice, which is the one judgement call in the file.

Findings: none to dispose of.

Verified in this session, not just asserted:

• With the file absent → read reviewer registry: ... no such file or directory, exit 1.
• With it present → the queue answers, correctly omits docs: correct lesson-094's premise and three reviewer findings from #401 #406 (carries a ## Review triage comment) and correctly surfaces chore(master): release 4.2.0 #405 (does not). chore(master): release 4.2.0 #405 was a real open PR nobody had triaged, invisible until this landed.
• After triaging chore(master): release 4.2.0 #405, the queue re-ran and surfaced feat: add the reviewer registry that makes the triage queue answerable #407 and fix(spec): record measured evidence on HIVE-384, and stop AC5 reading green #408 — so it re-opens on new output rather than latching clear.

One wrinkle found while testing, worth knowing before merge: the registry path is CWD-relative (harness/review-attestation.json), so dotf pr triage-queue only answers from a branch that has the file. Running it from fix/hive-384-spec-artifacts mid-session gave the original "no such file" error. This is invisible on dotfiles because the file merged long ago, and it self-resolves here once this hits master — but until then, the queue's answerability depends on which branch is checked out. Not worth a code change; worth not being surprised by.

Recommendation: merge on the human's call, with the unreviewed status on the record.