Context
src/settings/contributor-blacklist.ts:10 validates entries against GITHUB_LOGIN = /^[a-zA-Z0-9](?:[a-zA-Z0-9]|-(?=[a-zA-Z0-9])){0,38}$/, which rejects any login ending in [bot]. Its sibling src/settings/auto-close-exempt.ts (mirrored from packages/loopover-engine/src/settings/auto-close-exempt.ts) deliberately extends the same base pattern with (?:\[bot\])?, specifically because "a repo-specific bot integration...is exactly the kind of third-party automation identity a maintainer needs to exempt." A maintainer configuring settings.contributorBlacklist: [{login: "evilbot[bot]"}] gets it silently dropped with only a generic "not a valid GitHub login" warning. Bot accounts are a documented abuse vector elsewhere in this codebase (agent-actions.ts's PROTECTED_AUTOCLOSE_AUTHORS), so blacklisting one should be supported.
Requirements
- Extend
contributor-blacklist.ts's GITHUB_LOGIN pattern with the same (?:\[bot\])? suffix auto-close-exempt.ts already uses, so a bot login validates correctly.
- Verify the blacklist-enforcement code path (wherever
contributorBlacklist is actually checked against an incoming PR's author) correctly matches a [bot]-suffixed login end-to-end, not just that the config-parsing regex accepts it.
- Do not change
auto-close-exempt.ts — it's already correct and is the reference pattern.
Test Coverage Requirements
99%+ Codecov patch coverage on the changed regex and its enforcement path; add a regression test blacklisting a something[bot] login and confirming a PR from that author is actually blocked.
Deliverables
Expected Outcome
A maintainer can blacklist a malicious or unwanted bot account the same way they can already blacklist a human contributor.
Links & Resources
src/settings/contributor-blacklist.ts:10src/settings/auto-close-exempt.ts (packages/loopover-engine/src/settings/auto-close-exempt.ts, the correct reference pattern)src/settings/agent-actions.ts (PROTECTED_AUTOCLOSE_AUTHORS, documents bot accounts as a real abuse vector)
Context
src/settings/contributor-blacklist.ts:10validates entries againstGITHUB_LOGIN = /^[a-zA-Z0-9](?:[a-zA-Z0-9]|-(?=[a-zA-Z0-9])){0,38}$/, which rejects any login ending in[bot]. Its siblingsrc/settings/auto-close-exempt.ts(mirrored frompackages/loopover-engine/src/settings/auto-close-exempt.ts) deliberately extends the same base pattern with(?:\[bot\])?, specifically because "a repo-specific bot integration...is exactly the kind of third-party automation identity a maintainer needs to exempt." A maintainer configuringsettings.contributorBlacklist: [{login: "evilbot[bot]"}]gets it silently dropped with only a generic "not a valid GitHub login" warning. Bot accounts are a documented abuse vector elsewhere in this codebase (agent-actions.ts'sPROTECTED_AUTOCLOSE_AUTHORS), so blacklisting one should be supported.Requirements
contributor-blacklist.ts'sGITHUB_LOGINpattern with the same(?:\[bot\])?suffixauto-close-exempt.tsalready uses, so a bot login validates correctly.contributorBlacklistis actually checked against an incoming PR's author) correctly matches a[bot]-suffixed login end-to-end, not just that the config-parsing regex accepts it.auto-close-exempt.ts— it's already correct and is the reference pattern.Test Coverage Requirements
99%+ Codecov patch coverage on the changed regex and its enforcement path; add a regression test blacklisting a
something[bot]login and confirming a PR from that author is actually blocked.Deliverables
contributor-blacklist.ts'sGITHUB_LOGINpattern accepts[bot]-suffixed logins.Expected Outcome
A maintainer can blacklist a malicious or unwanted bot account the same way they can already blacklist a human contributor.
Links & Resources
src/settings/contributor-blacklist.ts:10src/settings/auto-close-exempt.ts(packages/loopover-engine/src/settings/auto-close-exempt.ts, the correct reference pattern)src/settings/agent-actions.ts(PROTECTED_AUTOCLOSE_AUTHORS, documents bot accounts as a real abuse vector)