Maskinöversatt från engelska — källa: reviewer-feedback-loop.md.
Implementeringsstatus: Designanteckning — kodifierar den stående minnesregeln om Codex-granskningspolling (
feedback_codex_review_loop.md) in i PRD-till-PR-pipelinen.Byggt idag: disciplinen (minnesreglerna
feedback_codex_review_loop.mdochfeedback_no_auto_merge_until_full_ci_and_review.md) — människor körgh api repos/{org}/{repo}/pulls/<n>/commentsmanuellt efter varje push och kör agenten igen på P1/P2.Mål-tillägg: automatiserad polling på
be-agent-service/apps/server/src/pipeline/codex-poll.ts, severitets-klassificerare, och återinträdes-hook in i Editor-steget. Idempotens via comment-id-spårning isummary.json. Ingen av denna kod existerar än; enrg "pulls/.*comments" be-agent-servicereturnerar inga träffar.
Externa granskare (Codex, CodeRabbit) postar inline-kommentarer efter varje push, inte bara vid initial PR-öppning. Att behandla deras kommentarer som rådgivande betyder att riktiga buggar slinker igenom. Loopen nedan behandlar varje oadresserad P1 / P2 som ett misslyckat test och kör Editor-steget igen automatiskt.
Pollingen
Efter varje git push kör Reviewer-feedback-agenten:
gh api repos/{org}/{repo}/pulls/{n}/comments
Svaret är en lista av inline-kommentarer, var och en bärande:
body— kommentartexten (ofta kategoriserad av Codex / CodeRabbit som P1 / P2 / P3).pathochline— var fyndet gäller.user.login— för att filtrera till kända granskar-bottar.created_at— för att sortera efter färskhet.
Agenten klassificerar varje kommentar efter allvarlighet (regex på vanliga granskarformat — **P1**, 🚨, Critical, osv.) och lagrar dem i PR:ns statusobjekt.
Allvarlighet → åtgärd
| Allvarlighet | Åtgärd |
|---|---|
| P1 | Hård blockering. Kör Editor igen med kommentaren som input. Lös innan merge — argumentera aldrig ned. |
| P2 | Mjuk blockering. Kör Editor igen om inte agenten har ett motiverat motargument commitat till PR-beskrivningen. |
| P3 | Kvittera i PR-beskrivningen; blockera inte. |
| Stil / nit | Kvittera tyst i PR-beskrivningen; blockera inte. |
Agenten argumenterar ned via en kommentar som:
Granskaren tog upp "X kan regressera under hög samtidighet". Den relevanta kodvägen är enkeltrådad per request-scope; samtidighet kan inte trigga denna väg. Ändrar inte.
Om granskaren svarar med en förfining fortsätter loopen.
Återinträde i editorn
När en P1 / P2 landar och agenten beslutar att fixa:
- Reviewer-feedback-agenten lägger till kommentaren som ett ärende i en scratchpad på worktree-branchen.
- Den startar Editorn igen med
inputs.review_findings = [...]plus den ursprungliga specen. - Editorns iterationsloop har nu två stoppvillkor: spec-tester går grönt OCH granskningsfynd åtgärdade.
- Efter den nya commiten kör Verifier igen och loopen upprepas.
Idempotens
Pollingen är idempotent — kommentarer försvinner inte, så återkörningar ser samma uppsättning. Agenten spårar "comment id → status" i summary.json så att:
- Kommentarer som redan adresserats i en tidigare iteration åtgärdas inte igen.
- Kommentarer som argumenterats ned triggar inte återinträde i varje loop.
- Granskar-comebacks (en ny kommentar på samma rad) triggar återinträde eftersom comment id:t är nytt.
När loopen ska kortslutas
Två fall där loopen avsiktligt avslutas utan att adressera en kommentar:
- Inaktuell kommentar — filen eller raden finns inte längre efter en refactor. Agenten postar ett "ej längre tillämpligt"-svar och går vidare.
- Utanför omfång — kommentaren refererar till beteende utanför denna PR:s spec. Agenten lägger upp en uppföljningsplan i
wiki/plans/och svarar med en länk.
Båda kräver att en motivering commitas till PR-beskrivningen så att granskare ser exit-resonemanget.
Varför detta inte är valfritt
Stående minnesregler:
feedback_codex_review_loop.md(tillagd 2026-04-25 efter att PR #325 landade med en Codex P1 missad under parallella auto-merges).feedback_no_auto_merge_until_full_ci_and_review.md(tillagd 2026-04-28 efter att PR #367 mergades med misslyckande dashboard-coverage / dashboard-server-required-jobs).
Båda föregår detta avsnitt men har samma form: externa granskar-bottar kan misslyckas tyst om man inte pollar, och parallella merges kan kapa förbi "required check"-grinden om man inte väntar på aggregatet grönt. Pipelinen kodifierar båda som grindar orkestreraren inte kan hoppa över.
Korsreferenser
- PRD-till-PR-pipeline — steg 7.
- Verifiering och bevis — dossiern Verifier producerar är oberoende av denna loop.
- Agentroller och modellroutning — Reviewer-rollen.
- Merge-flöde och PR-velocitet — merge-queue-grindar denna loop respekterar.