Bakgrunn
Issue #63 / PR #74 filtrerer hendelser utløst av botens egen login — men hendelser utløst av andre boter slipper fortsatt gjennom. Konkret hendelse 2026-07-22 (~16:02Z): CodeRabbit kjørte autofix på PR #74 og postet en «jeg er i gang, vennligst vent»-melding. Det ga en notifikasjon til bot-kontoen; siden latest_comment_url var null falt polleren tilbake til PR-body-en som prompt, og proxy-agenten omsatte den til en (feilaktig) delegering om å squash-merge PR #74 til feil base og lukke #63. Kodeagenten avslo, men kjeden viser at bot-til-bot-hendelser kan eskalere til handlingsordrer uten menneskelig intensjon.
To hull i dagens filter (begge bevisste valg i #74, dokumentert der):
- Aktør-sjekken sammenligner kun med botens egen login — andre bot-kontoer (
coderabbitai[bot], dependabot[bot], …) regnes som mennesker.
- Når
latest_comment_url er null filtreres det ikke i det hele tatt (fail-open for menneske-mentions i issue-body) — da blir prompten dessuten issue-/PR-body i stedet for den utløsende meldingen, som gir proxyen feil kontekst.
Foreslått løsning
I integrations/src/github/poller.ts / client.ts:
- Utvid aktør-filteret: hendelser der utløsende aktør er en bot-konto (login med
[bot]-suffiks, og/eller user.type === "Bot" fra API-svaret getResourceAuthor allerede henter) behandles som ikke-arbeidsordre: marker lest, debug-logg, ingen kø. Vurder en konfigurerbar allowlist (GITHUB_TRUSTED_BOTS) for boter som faktisk skal kunne gi arbeidsordrer.
- Interim-meldinger spesielt: CodeRabbits fremdriftsmeldinger («working on it», autofix-status) er støy selv om man skulle ønske andre CodeRabbit-events velkommen — bot-aktør-filteret over dekker dette enkelt ved å droppe alt fra bot-kontoer.
- Sekundært (kan skilles ut): når
latest_comment_url er null bør prompten merkes tydelig som «issue/PR-body, ikke en henvendelse», slik at proxyen ikke tolker en beskrivelse som en ordre.
Berørte filer
integrations/src/github/poller.ts — bot-aktør-filter før kø
integrations/src/github/client.ts — getResourceAuthor returnerer også user.type/login-suffiks
integrations/README.md, doc/log.md
Akseptansekriterier
Relatert
🤖 Generated with Claude Code
Bakgrunn
Issue #63 / PR #74 filtrerer hendelser utløst av botens egen login — men hendelser utløst av andre boter slipper fortsatt gjennom. Konkret hendelse 2026-07-22 (~16:02Z): CodeRabbit kjørte autofix på PR #74 og postet en «jeg er i gang, vennligst vent»-melding. Det ga en notifikasjon til bot-kontoen; siden
latest_comment_urlvar null falt polleren tilbake til PR-body-en som prompt, og proxy-agenten omsatte den til en (feilaktig) delegering om å squash-merge PR #74 til feil base og lukke #63. Kodeagenten avslo, men kjeden viser at bot-til-bot-hendelser kan eskalere til handlingsordrer uten menneskelig intensjon.To hull i dagens filter (begge bevisste valg i #74, dokumentert der):
coderabbitai[bot],dependabot[bot], …) regnes som mennesker.latest_comment_urler null filtreres det ikke i det hele tatt (fail-open for menneske-mentions i issue-body) — da blir prompten dessuten issue-/PR-body i stedet for den utløsende meldingen, som gir proxyen feil kontekst.Foreslått løsning
I
integrations/src/github/poller.ts/client.ts:[bot]-suffiks, og/elleruser.type === "Bot"fra API-svaretgetResourceAuthorallerede henter) behandles som ikke-arbeidsordre: marker lest, debug-logg, ingen kø. Vurder en konfigurerbar allowlist (GITHUB_TRUSTED_BOTS) for boter som faktisk skal kunne gi arbeidsordrer.latest_comment_urler null bør prompten merkes tydelig som «issue/PR-body, ikke en henvendelse», slik at proxyen ikke tolker en beskrivelse som en ordre.Berørte filer
integrations/src/github/poller.ts— bot-aktør-filter før køintegrations/src/github/client.ts—getResourceAuthorreturnerer ogsåuser.type/login-suffiksintegrations/README.md,doc/log.mdAkseptansekriterier
coderabbitai[bot](eller annen bot-konto) gir ingen event i proxy-agentens inbox; tråden markeres lest og skippes med debug-logg.GITHUB_TRUSTED_BOTSslipper gjennom som før.Relatert
🤖 Generated with Claude Code