@nevzatcirak/review-mcp 2.1.0 → 2.2.0-rc.2

package/NOTICE

@@ -17,7 +17,14 @@ review agent, licensed under the MIT License. In particular:
   question-answering, pull-request description and code-suggestion tools,
   including the self-review scoring of code suggestions,
 - the idea of reviewing only the files touched since the last review
-  (incremental review); only the idea follows PR-Agent, no code is copied.
+  (incremental review); only the idea follows PR-Agent, no code is copied,
+- the idea of per-repository settings read from a file in the reviewed
+  repository (PR-Agent's .pr_agent.toml; review-mcp's .review-mcp.toml); only
+  the idea follows PR-Agent, no code is copied,
+- the idea of checking a pull request against its issue (PR-Agent's ticket
+  compliance check: requirements met, not met and needing human
+  verification; review-mcp's issue compliance); only the idea follows
+  PR-Agent, no code or prompt text is copied.
 
 review-mcp is an independent reimplementation in Go. No PR-Agent source code
 is included in this repository; the logic, prompt design, and schemas were

package/README.md

@@ -187,9 +187,9 @@ except `job_result`).
 | `pr_info` | Which branch a pull request merges into and who has reviewed or approved it: human reviewers with their states, approval counts, required approvals and merge status where the provider exposes them. review-mcp's own reviews and comments are reported separately and never count as approvals. Also reports the CI results of the head commit (`ci`: state, counts and the failing checks), read from the provider; nothing is built or run. Read-only, no LLM call; see [Pull request status](docs/pr-info.md). |
 | `pr_comment_reply` | Replies to a pull request comment (inside the thread on Bitbucket Server and GitLab, and on GitHub for an inline comment; as a quoting PR-level comment on Gitea, and on GitHub for a general comment). |
 | `pr_comment_create` | Posts a new comment on a pull request, PR-level or on a changed line (`file` and `line`). A line outside the diff is refused, never posted at PR level instead. |
-| `pr_review` | Reviews a pull request with your LLM. The title, description, existing comments and diff are sent to your LLM endpoint. Optionally publishes the review: one overview comment, edited in place on later runs, and inline comments on the changed lines. The model is also given the head commit's CI results (failing and pending checks, and a CI line in the overview), the project's guidelines file (`.review-mcp/guidelines.md`, else `CONTRIBUTING.md`) and a listing of the directories the change touches, both read at the target branch so a pull request cannot rewrite its own rules. `focus` (`security`, `architecture`, `performance`, `ux`, `tests` or free text) reviews one area and never publishes; the findings of several focused reviews are merged by the client and published once with `findings` and `publish=true`, without another model call (the `multi_perspective_review` prompt describes the steps). With `incremental=true` (or `review.incremental`) it reviews only the files whose content changed since the last review it published, and lists the earlier findings the overview held without an inline comment on files that did not change; nothing changed means no model call and nothing posted. See [Reviewing pull requests](docs/review.md#incremental-review). |
+| `pr_review` | Reviews a pull request with your LLM. The title, description, existing comments and diff are sent to your LLM endpoint. Optionally publishes the review: one overview comment, edited in place on later runs, and inline comments on the changed lines. The model is also given the head commit's CI results (failing and pending checks, and a CI line in the overview), the project's guidelines file (`.review-mcp/guidelines.md`, else `CONTRIBUTING.md`) and a listing of the directories the change touches, both read at the target branch so a pull request cannot rewrite its own rules. `focus` (`security`, `architecture`, `performance`, `ux`, `tests`, `docs` or free text) reviews one area and never publishes; the findings of several focused reviews are merged by the client and published once with `findings` and `publish=true`, without another model call (the `multi_perspective_review` prompt describes the steps). With `incremental=true` (or `review.incremental`) it reviews only the files whose content changed since the last review it published, and lists the earlier findings the overview held without an inline comment on files that did not change; nothing changed means no model call and nothing posted. See [Reviewing pull requests](docs/review.md#incremental-review). It also checks the pull request against the issue it implements (requirements met, not met, needing human verification, and a verdict): an issue the pull request names on its own host, or one the client passes as `issue_context`, for example from a tracker MCP server; review-mcp never contacts trackers itself. See [Issue compliance](docs/review.md#issue-compliance). |
 | `pr_ask` | Answers a free-text question about a pull request, grounded in its title, description and diff. Optionally publishes the question and answer as a PR comment. |
-| `pr_describe` | Describes a pull request with your LLM: a title, the change types, a short summary and a walkthrough of the changed files. The title, description, branch names, commit messages and diff are sent to your LLM endpoint. By default it only reads; `publish=true` writes to the pull request, either one comment that later runs edit in place or a marked region at the end of the description (the author's text is never changed), and `update_title=true` also replaces the title. Files the model did not describe are listed, never padded in. See [Describing pull requests](docs/describe.md). |
+| `pr_describe` | Describes a pull request with your LLM: a title, the change types, a short summary and a walkthrough of the changed files. The title, description, branch names, commit messages and diff are sent to your LLM endpoint. By default it only reads; `publish=true` writes to the pull request, either one comment that later runs edit in place or a marked region at the end of the description (the author's text is never changed), and `update_title=true` also replaces the title. Files the model did not describe are listed, never padded in. The pull request's issue (or `issue_context`) is used as context, without a verdict. See [Describing pull requests](docs/describe.md). |
 | `pr_improve` | Suggests code changes for a pull request with your LLM: for each suggestion the existing and the improved code, a label and a score from 0 to 10 given by a second, self-review model call; suggestions below `improve.min_score` are dropped and counted, never silently lost. Each suggestion is checked against the head version of the file before it is called anchored; ones that cannot be are marked, not hidden. The title, description, branch names, existing comments and diff are sent to your LLM endpoint, with the project's guidelines file and the listing of the touched directories read at the target branch, as for `pr_review`. By default it only reads; `publish=true` writes to the pull request: one overview comment that later runs edit in place, and an inline comment on each verified suggestion that is on changed lines of one hunk (not repeated on later runs), with the change as a native suggestion block on GitHub and GitLab and as a diff block on Gitea and Bitbucket Server. See [Suggesting code changes](docs/improve.md). |
 | `job_result` | Returns the result of a `pr_review`, `pr_ask`, `pr_describe` or `pr_improve` call that took longer than `wait_seconds` and answered with a `job_id` instead. stdio only; see [Slow endpoints](docs/review.md#slow-endpoints). |
 
@@ -204,6 +204,8 @@ except `job_result`).
 - [GitHub](docs/github.md): the token and its permissions, URL shapes and GitHub Enterprise Server, how the API address is derived, rate limits, the 3000-file and 250-commit limits, comment threads and why resolved state is not shown, replies and edits, one review per run, native suggestion blocks and their re-indentation rule, `pr_info` (approvals from rulesets and classic protection, the merge status), the description edit, repository context, and what is not supported.
 - [GitLab](docs/gitlab.md): the token and its scopes, URL shapes (nested groups, a context path), the minimum version 16.0, the diff base and the "diff not ready" case, the diff limits, rate limits, comment threads and replies, inline discussions and native suggestions, quick-action safety (what is sanitised, the diff fallback, the description refusal), `pr_info` (reviewers, approvals, the merge status), CI from commit statuses and what is not read, repository context, a proxy or `external_url` that differs from the base URL, and what is not supported.
 - [Pull request status](docs/pr-info.md): what `pr_info` reports (target branch, human reviewers, approvals, merge status, CI results), where each fact comes from, and why review-mcp's own reviews are not reviewers.
+- [Issue compliance](docs/review.md#issue-compliance): `pr_review` checks the pull request against its issue (met, not met, needs verification) from the provider's own issues or an `issue_context` the client fetches from any tracker; budgeted, fenced, never followed as instructions; [with a tracker MCP server](docs/setup.md#with-a-tracker-mcp-server).
+- [Repository config](docs/repo-config.md): a `.review-mcp.toml` in the reviewed repository, read at the target branch, tunes its reviews (language, ignore rules, guidelines paths, toggles, tighter caps, extra instructions, default focuses, documentation style) within an allow-list that never reaches hosts, models, limits or secrets.
 - [Repository context](docs/repo-context.md): opt-in, stdio only: shows the model where the symbols a pull request changes are used elsewhere in the project (a cached `git` fetch of the head, `git grep`, a budgeted prompt block), its configuration, the cache, the security properties, the coverage line and the evaluation harness.
 - [Getting started](docs/getting-started.md): the minimal configuration and the diff budget in detail.
 - [Troubleshooting](docs/troubleshooting.md): the `diag` commands and every error sentence.
@@ -218,8 +220,10 @@ lists every adapted file and carries PR-Agent's license. See it for details on
 what was derived and
 `docs/research/pr-agent-porting-map.md` for the pinned upstream revision
 studied during the porting research. The idea of reviewing only the files
-touched since the last review follows PR-Agent's incremental review (MIT); no
-code is copied.
+touched since the last review follows PR-Agent's incremental review (MIT), and
+per-repository settings (`.review-mcp.toml`) follow PR-Agent's `.pr_agent.toml`
+(MIT), and issue compliance follows PR-Agent's ticket compliance check (MIT);
+no code is copied.
 
 ## License
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@nevzatcirak/review-mcp",
-  "version": "2.1.0",
+  "version": "2.2.0-rc.2",
   "description": "MCP server for AI-assisted pull-request review on Gitea and Bitbucket Server.",
   "keywords": [
     "mcp",
@@ -23,12 +23,12 @@
     "node": ">=18"
   },
   "optionalDependencies": {
-    "@nevzatcirak/review-mcp-linux-x64": "2.1.0",
-    "@nevzatcirak/review-mcp-linux-arm64": "2.1.0",
-    "@nevzatcirak/review-mcp-darwin-x64": "2.1.0",
-    "@nevzatcirak/review-mcp-darwin-arm64": "2.1.0",
-    "@nevzatcirak/review-mcp-win32-x64": "2.1.0",
-    "@nevzatcirak/review-mcp-win32-arm64": "2.1.0"
+    "@nevzatcirak/review-mcp-linux-x64": "2.2.0-rc.2",
+    "@nevzatcirak/review-mcp-linux-arm64": "2.2.0-rc.2",
+    "@nevzatcirak/review-mcp-darwin-x64": "2.2.0-rc.2",
+    "@nevzatcirak/review-mcp-darwin-arm64": "2.2.0-rc.2",
+    "@nevzatcirak/review-mcp-win32-x64": "2.2.0-rc.2",
+    "@nevzatcirak/review-mcp-win32-arm64": "2.2.0-rc.2"
   },
   "files": [
     "bin/review-mcp.js",