self-development: scope kelos-planner, kelos-reviewer, and kelos-api-reviewer with commentOn#1205
self-development: scope kelos-planner, kelos-reviewer, and kelos-api-reviewer with commentOn#1205kelos-bot[bot] wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
🤖 Kelos Worker Agent @gjkim42
Review Summary
Verdict: COMMENT (cannot self-approve)
Overall correctness: patch is correct
Scope: Adds commentOn to the issue_comment filters of kelos-planner (Issue) and kelos-reviewer (PullRequest), and deletes the now-redundant step-0 PR-vs-issue guard from the planner prompt. Completes the cleanup deferred by #1081 / partially started in 1a61816.
Findings Overview
| Priority | Count | File:Line | Summary |
|---|---|---|---|
| P0 | 0 | — | none |
| P1 | 0 | — | none |
| P2 | 0 | — | none |
| P3 | 0 | — | none |
Key takeaways
- Both filter values (
Issue,PullRequest) match the+kubebuilder:validation:Enum=Issue;PullRequestmarker onWebhookFilter.CommentOn(api/v1alpha1/taskspawner_types.go:484). - Removing the
### 0. Confirm the target is an issueblock fromkelos-planner.yamlis safe — the filter now enforces the same constraint at the webhook layer, and no other prompt step depends on that guard. kelos-reviewer.yaml'sbranchtemplate already uses the safe{{with index . "Branch"}}{{.}}{{else}}main{{end}}fallback (line 82), so no additional change is needed there.kelos-squash-commits.yamlis correctly out of scope — it already gotcommentOn: PullRequestin 1a61816 (verified at line 16)./kind cleanup+release-note: NONEis the right classification for aself-development/-only change.
gjkim42
left a comment
There was a problem hiding this comment.
Let'a apply this to kelos api reviewer as well
/kelos pick-up
|
🤖 Kelos Task Status Task |
gjkim42
left a comment
There was a problem hiding this comment.
Does kelos api reviewer work for an issue as well? (Based on the prompt?)
/kelos pick-up
then squash commits
|
🤖 Kelos Task Status Task |
Add the commentOn filter (introduced in #1081) to the three remaining webhook-driven TaskSpawners so each declares its intended subject at the filter layer instead of relying on prompt-side workarounds: - kelos-planner: add commentOn: Issue and drop the now-redundant step-0 prompt block that exited if the target was a PR. - kelos-reviewer: add commentOn: PullRequest to the issue_comment filter so /kelos review on a plain issue no longer spawns a task whose prompt unconditionally runs gh pr view and git diff. - kelos-api-reviewer: split the issue_comment filter into two entries with explicit commentOn: Issue and commentOn: PullRequest. This spawner is intentionally dual-mode (the prompt dispatches on gh pr view to handle both subjects), so two explicit filters make the dual-mode intent visible at the webhook layer. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
ba5c0c6 to
09b28cb
Compare
What type of PR is this?
/kind cleanup
What this PR does / why we need it:
Adds the
commentOnfilter field (introduced in #1081) to the three remaining webhook-driven TaskSpawners that previously relied on prompt-side workarounds or no guard at all:kelos-planner.yaml— addscommentOn: Issueto theissue_commentfilter and deletes the now-redundant### 0. Confirm the target is an issueprompt block./kelos plantyped on a PR is now rejected at the webhook layer instead of spawning an Opus task that bails at step 0.kelos-reviewer.yaml— addscommentOn: PullRequestto theissue_commentfilter./kelos reviewtyped on a plain issue can no longer spawn a task whose prompt unconditionally callsgh pr viewandgit diff origin/main...HEAD. Thepull_request_reviewfilter entry is already PR-only by event type, so no change is needed there.kelos-api-reviewer.yaml— splits theissue_commentfilter into two entries with explicitcommentOn: IssueandcommentOn: PullRequest. This spawner is intentionally dual-mode (the prompt dispatches ongh pr viewto handle both issues and PRs), so the filter cannot collapse to a single subject; two explicit filters make the dual-mode intent visible at the webhook layer instead of relying oncommentOnbeing absent.kelos-squash-commits.yamlalready gainedcommentOn: PullRequestin 1a61816, so no further change is needed for that spawner.After this change, every webhook-driven TaskSpawner declares its intended subject at the filter layer.
Which issue(s) this PR is related to:
Fixes #1089
Special notes for your reviewer:
branchfallback forkelos-reviewer); Configuration Alignment: kelos-reviewer accepts /kelos review on plain issues — missing PR-vs-issue guard and unsafe branch template #1060 can be closed once this lands.kelos-reviewerbranchtemplate already uses the safe{{with index . "Branch"}}{{.}}{{else}}main{{end}}fallback, so no change is needed there.kelos-api-reviewer, the prompt-sidegh pr viewdispatch is retained because both subjects are accepted on the same event/bodyPattern and the prompt still needs to know which subject it is handling.Does this PR introduce a user-facing change?