Configuration Alignment: kanon-reviewer filters drop the worker's own /kelos review — automated worker→reviewer handoff never fires (Kanon PR #6: comment by kelos-bot[bot], 0 reviews)

Start with kanon-development/kanon-reviewer.yaml, then inspect kanon-workers.yaml to understand the dependent handoff and compare the related resolution in issue #1221. Update the webhook filters so the worker bot's /kelos review comment is admitted while retaining the manual maintainer path, and verify the bot's submitted review cannot trigger another review.

🤖 Kelos Agent @gjkim42

Configuration Alignment: kanon-reviewer filters drop the worker's own /kelos review — the automated worker→reviewer handoff never fires

Summary

kanon-workers ends every run by self-requesting a review (steps 11a/11b):

Then request a review by posting a comment on the PR: gh pr comment kanon-task-{{.Number}} --body "/kelos review". The reviewer agent will post its findings asynchronously as a PR review.

But kanon-reviewer's webhook filters can never match that comment, because the worker posts it as the bot, not as gjkim42. The promised async review never happens — kanon-reviewer is only reachable when gjkim42 manually types /kelos review.

Evidence (Kanon PR #6)

On the one generated PR so far, the worker posted the handoff comment and the reviewer stayed silent:

• Comment on PR #6: body /kelos review, author kelos-bot[bot] (gh api repos/kelos-dev/kanon/issues/6/comments)
• Reviews on PR #6: none (gh api repos/kelos-dev/kanon/pulls/6/reviews returns [])

So the worker's /kelos review was posted and produced zero reviews — the handoff died at the filter.

Root cause (kanon-development/kanon-reviewer.yaml)

The githubWebhook block filters the bot out twice over:

when:
  githubWebhook:
    repository: kelos-dev/kanon
    excludeAuthors:
      - kelos-bot[bot]          # (1) drops every bot-authored event, globally
    events: [issue_comment, pull_request_review]
    filters:
      - event: issue_comment
        action: created
        bodyPattern: /kelos review
        commentOn: PullRequest
        state: open
        author: gjkim42         # (2) requires the comment author to be gjkim42
      - event: pull_request_review
        action: submitted
        bodyPattern: /kelos review
        state: open
        author: gjkim42         # same restriction

The worker comment is authored by kelos-bot[bot] (confirmed on PR #6), so it is rejected by both excludeAuthors (1) and the per-filter author: gjkim42 (2). There is no filter path that admits the bot's review request.

This is the Kanon analog of the kelos-side #1221 (kelos-reviewer/kelos-api-reviewer drop bot-authored review requests). The fix has not been ported to kanon-development/, and kanon-workers here actively depends on the handoff working.

Why this matters

• Every worker-produced Kanon PR reaches human review with no kanon-reviewer pass, despite the worker prompt asserting one will run.
• kanon-reviewer is effectively dead for the automated pipeline; it only fires on a manual maintainer comment.
• The worker prompt's claim ("The reviewer agent will post its findings asynchronously") is misleading given the current filters.

Proposed fix (kanon-development/kanon-reviewer.yaml only)

The maintainer approval gate already lives on kanon-workers (/kelos pick-up requires author: gjkim42). Once a worker is running, the review request is an internal pipeline step and should be allowed from the bot. Concretely:

1. Add a filter entry to kanon-reviewer that admits the worker's bot-authored /kelos review request, e.g. a second issue_comment filter without the author: gjkim42 restriction (keeping commentOn: PullRequest, bodyPattern: /kelos review, state: open), and
2. Remove kelos-bot[bot] from the top-level excludeAuthors (since it is applied globally and would otherwise still drop the bot comment admitted in step 1).

Keep the existing author: gjkim42 manual path so maintainers can still trigger reviews directly. Verify this doesn't create a loop: kanon-reviewer submits via gh pr review (its review bodies do not contain /kelos review), so admitting the bot does not re-trigger the reviewer on its own output.

Alternatively, mirror whatever resolution is chosen for #1221 so the two reviewers stay consistent.

Scope

• Reasoning limited to kanon-development/ files (kanon-reviewer.yaml, with kanon-workers.yaml as the dependent consumer).
• Not a duplicate of #1221, which targets the self-development/ kelos-reviewer/kelos-api-reviewer files; this is the un-ported Kanon counterpart with its own evidence (Kanon PR #6).