A pull request comment that asks for a review now posts a real review, not a plain comment: the review file decides, the event no longer does.
Verified with deno fmt, lint and check.
Reviewed-on: #9
Co-authored-by: bot <temeddix@gmail.com>
Co-committed-by: bot <temeddix@gmail.com>
The review file starts with `Approved` or `Changes requested` instead of `Yes`/`No`/`With fixes`. The match is still the whole trimmed first line; `run.ts` prepends ✅, 🛑, or 💬 when posting, so the mark never takes part in the match.
Verified: `deno fmt`, `deno lint`, `deno check` pass; a scratch run of the matcher maps `Approved` → APPROVED, `Changes requested` → REQUEST_CHANGES, and `Approved, mostly`, `✅ Approved`, `Yes` → COMMENT.
Reviewed-on: #8
Co-authored-by: Danny Kim <temeddix@gmail.com>
Co-committed-by: Danny Kim <temeddix@gmail.com>
The reviewer writes its review to a file whose first line is the verdict, instead of relying on a narration-free final message. Sonnet put `Yes` after three paragraphs of narration on memona #936 (review 595), which the fail-closed verdict posted as a plain comment.
Reviewed-on: #7
Co-authored-by: Danny Kim <temeddix@gmail.com>
Co-committed-by: Danny Kim <temeddix@gmail.com>
Optional `model` input. Defaults move to the mid tiers, `claude-sonnet-5` and `gpt-5.6-terra`, since a run follows a fixed template plus the project's checks; a workflow can still pass a bigger model.
Reviewed-on: #6
Co-authored-by: Danny Kim <temeddix@gmail.com>
Co-committed-by: Danny Kim <temeddix@gmail.com>
The reviewer drops a finding the author has answered in the PR comments as intended or a false alarm, once the code or docs make that clear. Pairs with memona's merge-branch gate loop.
Reviewed-on: #5
Co-authored-by: Danny Kim <temeddix@gmail.com>
Co-committed-by: Danny Kim <temeddix@gmail.com>
The agent and the bot are now two accounts, and the runner is one Deno script.
- `author-token` (was `gitea-token`): commits, pushes, and opens pull requests; the agent sees it as `GITEA_TOKEN`, and commits use that account's login and email.
- `reviewer-token`: posts comments and reviews as the bot; withheld from the agent's environment so it can never approve as the bot.
- A `pull_request` run posts a review instead of a comment: `REQUEST_CHANGES` when the response mentions `@bot`, `COMMENT` when the run failed, `APPROVED` otherwise. Gitea refuses self-approval, so the two accounts must differ.
- The reviewer checks the whole repository against `commons/code-rules`, which is fetched and embedded in the prompt, and requests changes for violations even when the diff did not cause them.
- `run.ts` replaces the three shell scripts plus `jq`, `envsubst`, and `ansifilter`; only `deno` is added to the install step, per the rules' Deno-over-Node policy. A `.gitea` workflow runs `deno fmt`, `lint`, and `check`.
Callers must rename `gitea-token` and add `reviewer-token` (`write:issue` and `write:repository` scopes). A rejection stays until the bot reviews again, so callers that want it lifted after a fix should trigger on `pull_request: [opened, synchronize]`.
Verified with a fake `claude` binary against this PR in an isolated `HOME`: git author configured from the token, prompt rendered with rules and comment history, events streamed, reviewer token absent from the agent's environment, review posted (then deleted).
Reviewed-on: #1
Co-authored-by: Danny Kim <temeddix@gmail.com>
Co-committed-by: Danny Kim <temeddix@gmail.com>
temeddix