A finding about one line now lands on that line of the diff: the agent writes anchors as JSON, and the review posts them with the body in one call. Bad entries fail the run, and an anchor Gitea refuses falls back to posting the body alone.
Verified with deno fmt, lint and check.
Reviewed-on: #10
Co-authored-by: bot <temeddix@gmail.com>
Co-committed-by: bot <temeddix@gmail.com>
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>
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>