Conversational re-reviews: feed the previous review thread back #79

New issue

Closed

opened 2026-10-15 19:45:10 +00:00 by agent-pi · 1 comment

agent-pi commented

2026-10-15 19:45:10 +00:00

Collaborator

Evidence from #75: waves 480-483 re-raised items effectively settled in wave 479's thread (the agents example style, the keyless-server wording), and each wave was reviewed as if none of the discussion had happened.

Re-reviews should include the PR's prior WuMing review comments and the responses to them, so each wave continues the conversation instead of restarting it.

Every push to a PR triggers a fresh review with no memory of the previous one. Findings that were answered, fixed, or declined in earlier waves get re-litigated, because the reviewer never sees its own prior thread or the responses to it. Evidence from #75: waves 480-483 re-raised items effectively settled in wave 479's thread (the `agents` example style, the keyless-server wording), and each wave was reviewed as if none of the discussion had happened. Re-reviews should include the PR's prior WuMing review comments and the responses to them, so each wave continues the conversation instead of restarting it.

agent-pi added this to the Review memory milestone

2026-10-15 19:45:10 +00:00

agent-pi added the

Kind/Feature

Priority

High

labels

2026-10-15 19:45:10 +00:00

agent-pi referenced this issue

2026-10-16 23:38:44 +00:00

action.yml missing wave-1 inputs (verify, min_severity) #107

agent-pi commented

2026-10-16 23:39:09 +00:00

Author

Collaborator

Wave 2 plan (convergence: within-PR memory and bounds). Explored the code; the reviews API already gives us most of the raw material.

Findings from exploration

ForgejoClient.list_review_comment_bodies() already walks GET /pulls/{index}/reviews + per-review inline comments — but flattens to bodies only, discarding author, commit_id, and timestamps.
Forgejo review objects carry commit_id (the SHA the review ran against) — prior-wave state is available statelessly, no storage needed.
Agent prompts are assembled in src/wuming/agents/; PR thread comments are posted via ForgejoClient.post_comment().
Wave 1 (severity floor + verification) is merged; the remaining loud failure class is waves re-raising settled items — waves 480–483 of #75 re-litigated wave 479's thread.

Plan of attack for this issue (conversational re-reviews)

Branch: feat/issue-79-review-context (after #107 fix-up merges)
Refactor the reviews fetch into a structured list_reviews() (id, commit_id, body, inline comments with path/author/body/created), reusing it for the existing marker dedup
Build a previous review context block: the most recent WuMing review (identified by the ## WuMing review-body prefix) + PR-thread comments posted after it (human responses), filtered per agent to that agent's routed files, hard-capped in size
Inject into each agent's system prompt with language: already-raised findings need not repeat, answered/declined items must not be re-raised without new evidence
Config: WUMING_REVIEW_CONTEXT (default on; false disables) — action.yml input in the same PR
Docs: README config table, CLAUDE.md env list, Release-Notes.md
Tests: TDD via tryke (context builder, per-agent filtering, cap, disable switch)

Sequencing: #107 fix-up → this → #85 (skip unchanged since last review commit_id) → #84 (round cap + low-only soft stop). #80/#77 (cross-PR ground) are wave 3.

Wave 2 plan (convergence: within-PR memory and bounds). Explored the code; the reviews API already gives us most of the raw material. **Findings from exploration** - `ForgejoClient.list_review_comment_bodies()` already walks `GET /pulls/{index}/reviews` + per-review inline comments — but flattens to bodies only, discarding author, `commit_id`, and timestamps. - Forgejo review objects carry `commit_id` (the SHA the review ran against) — prior-wave state is available statelessly, no storage needed. - Agent prompts are assembled in `src/wuming/agents/`; PR thread comments are posted via `ForgejoClient.post_comment()`. - Wave 1 (severity floor + verification) is merged; the remaining loud failure class is waves re-raising settled items — waves 480–483 of #75 re-litigated wave 479's thread. **Plan of attack for this issue (conversational re-reviews)** - Branch: `feat/issue-79-review-context` (after #107 fix-up merges) - Refactor the reviews fetch into a structured `list_reviews()` (id, `commit_id`, body, inline comments with path/author/body/created), reusing it for the existing marker dedup - Build a *previous review context* block: the most recent WuMing review (identified by the `## WuMing` review-body prefix) + PR-thread comments posted after it (human responses), filtered per agent to that agent's routed files, hard-capped in size - Inject into each agent's system prompt with language: already-raised findings need not repeat, answered/declined items must not be re-raised without new evidence - Config: `WUMING_REVIEW_CONTEXT` (default on; `false` disables) — action.yml input in the same PR - Docs: README config table, CLAUDE.md env list, Release-Notes.md - Tests: TDD via tryke (context builder, per-agent filtering, cap, disable switch) Sequencing: #107 fix-up → this → #85 (skip unchanged since last review `commit_id`) → #84 (round cap + low-only soft stop). #80/#77 (cross-PR ground) are wave 3.

agent-pi referenced this issue

2026-10-16 23:39:10 +00:00

Skip unchanged files on re-review #85

agent-pi referenced this issue

2026-10-16 23:39:10 +00:00

Convergence controls: max rounds / diminishing-returns stop #84

agent-pi referenced this issue

2026-10-16 23:40:57 +00:00

Add verify and min_severity inputs to action.yml #108

agent-pi referenced this issue from a pull request that will close it,

2026-10-17 01:11:56 +00:00

Feed the previous review thread back into re-reviews #109