Shows the user's own pull request under Mergen as soon as the branch protection of its base lets the user merge it; with a hint to rebase when main moved on.
Shows the user's own pull request under Mergen as soon as the branch protection of its base lets the user merge it; with a hint to rebase when main moved on.
See doc/prs.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The official approvals and required checks of the base branch decide, not another human's approval;
behind its base, the hint says to rebase first.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
werkrevisor: YELLOW / HUMAN_REVIEW for 6953cf7d7e706de04b7aadf27b86b92b1e1587bd.
The result comment of werkrevisor holds the details.
werkrevisor: YELLOW / HUMAN_REVIEW for `6953cf7d7e706de04b7aadf27b86b92b1e1587bd`.
The result comment of werkrevisor holds the details.
<!-- werkrevisor-review:6953cf7d7e706de04b7aadf27b86b92b1e1587bd -->
Doc example contradicts test fixture, severity unknown, counted as medium (werkrevisor)
hint; Jev: real 0.81, severity 1.3 of 3
The Problem section says "e.g. mi/werkdock needs no approval and only the check werkator", but the integration test fixture in GiteaSourceFetchTest configures mi/werkdock's main with required_approvals: 1 (and status_check_contexts: ["werkator"]). The Scenario#94.02 prose, naming this property for "werkdock", and the matching GiteaSourceTest (Protection(0, ["werkator"]) named werkdock) use the same example name with a 0-approval protection. The behaviour tested is correct; only the narrative example is out of sync with the integration fixture for the same repo, which a reader verifying the doc against the test would notice.
**Doc example contradicts test fixture**, severity unknown, counted as medium (werkrevisor)
hint; Jev: real 0.81, severity 1.3 of 3
The Problem section says "e.g. `mi/werkdock` needs no approval and only the check `werkator`", but the integration test fixture in `GiteaSourceFetchTest` configures `mi/werkdock`'s `main` with `required_approvals: 1` (and `status_check_contexts: ["werkator"]`). The Scenario#94.02 prose, naming this property for "werkdock", and the matching `GiteaSourceTest` (`Protection(0, ["werkator"])` named `werkdock`) use the same example name with a 0-approval protection. The behaviour tested is correct; only the narrative example is out of sync with the integration fixture for the same repo, which a reader verifying the doc against the test would notice.
Awkward phrasing in Open Questions, severity unknown, counted as medium (werkrevisor)
hint; Jev: real 0.75, severity 1.0 of 3
The Open-Questions item reads "Each other one counts as an agent's, also that of a colleague; this PR does not change that." The phrase "an agent's" is incomplete (a noun is missing, likely "as an agent's pull request" or similar) and "that of a colleague" reads as a stray reference. The meaning can be guessed, but the sentence as written is unclear.
**Awkward phrasing in Open Questions**, severity unknown, counted as medium (werkrevisor)
hint; Jev: real 0.75, severity 1.0 of 3
The Open-Questions item reads "Each other one counts as an agent's, also that of a colleague; this PR does not change that." The phrase "an agent's" is incomplete (a noun is missing, likely "as an agent's pull request" or similar) and "that of a colleague" reads as a stray reference. The meaning can be guessed, but the sentence as written is unclear.
hint 3 changed file(s) that neither weaken the checks, touch security nor show a risk category of jvm-spring-backend according to Jev
hint 1 finding(s) of low severity or rated minor by Jev: dashboard/README.md:298-300
hint model recommends merge with caution
Findings
Documentation Mismatch at dashboard/README.md:298-300, severity unknown, counted as medium
hint; Jev: real 0.85, severity 2.3 of 3
The README's new Mergen description states "in each case no automerge scheduled", claiming this universal qualifier for the protected-own-PR, unprotected-own-PR, and foreign-PR cases. However, the code path for the unprotected-own-PR case in ownReviewFlags (when pr.protection == null and another human approved) does not check pr.automerge. Concretely: a user's own pull request on an unprotected branch, approved by another human, with Gitea's automerge scheduled, will still receive a merge flag and the "approved von …" text — contradicting the documented universal behavior. The PR document's Scenario#94.05 says "as before" for the unprotected case, confirming the code's behavior was intentionally left unchanged; the README update overstates what the code does. Either the README should restrict the qualifier to the protected and foreign cases, or ownReviewFlags should skip a turn with !pr.automerge.
Classifier
11 of 11 units passed all questions (1 PR document(s)).
2 answers ignored because of a confidence below [classifier] min_confidence.
Usage: model `openrouter/minimax/minimax-m3`, LLM done, tokens counted before the call 36784, calls 1, tokens in 35593 / out 34656 (reasoning included in out), duration 437.0 s, cost 0.0522 USD (reported), classifier `jev-1.13.0` calls 11, tokens in 9085, cost 0.0004 USD, finding judge `jev-1.13.0` calls 1, tokens in 2992, cost 0.0001 USD, build file judge `jev-1.13.0` calls 3, tokens in 7105, cost 0.0003 USD, phases: path_judge 0.2 s, classifier 0.8 s, context 0.2 s, model_review 435.1 s, finding_judge 0.2 s, config: defaults + host + repository (.werkrevisor.toml at main ec7c982).
Reviewed head `38b5560a7a2d3a23909a51d8f866abda8d2c995b` against base `ec7c982bf0ff8251261a1f350ac4ab213d837abb`, werkrevisor 0.52.0.
<!-- werkrevisor:38b5560a7a2d3a23909a51d8f866abda8d2c995b -->
<!-- werkrevisor-verdict:GREEN -->
<!-- werkrevisor-blocks:7f14541c45a4e865f4e7bb8a40003d0c,ffc232af26bc118884f92c3923e9087f,605b30bb7ecec726ae5dc10ae769b2ee,27bb51ae1638a7afcaaab4997970e873,fa38efd2a8e6162fc2ffc9c631bb77d4,9a1968289fd0d296be75d7cb2ace525c,177e331d62af71d3294be245c80ac2bb,b2cf0c7f90254469da5cfd1435f544fb,166a2eb906988da7cda85614b268dc60,411df6622f49b7b8cecc179c0218f9a7,777f9997e0c2741cd175706ec5c558fa,c9799b204663345a71a1e528eb27927b,eca0d1fd5d58d062385bce6da8232beb,266c0e4babbdb2c14b7a2b023948e6d1,8c231907af38e345f34e793118c7ea89,c9acc3297d2710dc689e6fa424c9c933,d27f6432de8f2112348cb91a961919b3,dca7daf53355dc6759f19da95e3d464d,0c00b04cd3fc1bd362961d9c0ba06452,dd4e6e3f48a0415580fc28be519ce6e8,4925ecff01b3875cd17d84efe6d64038,a3b3970441144745360d3f3785f506a4,f3c760d241969eb01f6cac37313af26b,166fdf1d565a3f1ae17139422d93652a,b7f48f7ec6273c5eee2de0b863ff8a2e,4174c2c33ca8efed885dfc5ddc4d1731 -->
## 🟢 werkrevisor: GREEN / PASS
Change kind: `feature_with_tests`.
### Reasons
- **hint** 3 changed file(s) that neither weaken the checks, touch security nor show a risk category of jvm-spring-backend according to Jev
- **hint** 1 finding(s) of low severity or rated minor by Jev: dashboard/README.md:298-300
- **hint** model recommends merge with caution
### Findings
1. **Documentation Mismatch** at `dashboard/README.md:298-300`, severity unknown, counted as medium
hint; Jev: real 0.85, severity 2.3 of 3
The README's new Mergen description states "in each case no automerge scheduled", claiming this universal qualifier for the protected-own-PR, unprotected-own-PR, and foreign-PR cases. However, the code path for the unprotected-own-PR case in `ownReviewFlags` (when `pr.protection == null` and another human approved) does not check `pr.automerge`. Concretely: a user's own pull request on an unprotected branch, approved by another human, with Gitea's automerge scheduled, will still receive a `merge` flag and the "approved von …" text — contradicting the documented universal behavior. The PR document's Scenario#94.05 says "as before" for the unprotected case, confirming the code's behavior was intentionally left unchanged; the README update overstates what the code does. Either the README should restrict the qualifier to the protected and foreign cases, or `ownReviewFlags` should skip a turn with `!pr.automerge`.
### Classifier
11 of 11 units passed all questions (1 PR document(s)).
2 answers ignored because of a confidence below [classifier] min_confidence.
<sub>
Usage: model `openrouter/minimax/minimax-m3`, LLM done, tokens counted before the call 36784, calls 1, tokens in 35593 / out 34656 (reasoning included in out), duration 437.0 s, cost 0.0522 USD (reported), classifier `jev-1.13.0` calls 11, tokens in 9085, cost 0.0004 USD, finding judge `jev-1.13.0` calls 1, tokens in 2992, cost 0.0001 USD, build file judge `jev-1.13.0` calls 3, tokens in 7105, cost 0.0003 USD, phases: path_judge 0.2 s, classifier 0.8 s, context 0.2 s, model_review 435.1 s, finding_judge 0.2 s, config: defaults + host + repository (.werkrevisor.toml at main ec7c982).<br>
Reviewed head `38b5560a7a2d3a23909a51d8f866abda8d2c995b` against base `ec7c982bf0ff8251261a1f350ac4ab213d837abb`, werkrevisor 0.52.0.
</sub>
werkrevisor: GREEN / PASS for 38b5560a7a2d3a23909a51d8f866abda8d2c995b.
The result comment of werkrevisor holds the details.
werkrevisor: GREEN / PASS for `38b5560a7a2d3a23909a51d8f866abda8d2c995b`.
The result comment of werkrevisor holds the details.
<!-- werkrevisor-review:38b5560a7a2d3a23909a51d8f866abda8d2c995b -->
ai-reviewer
removed review request for mi 2026-10-20 11:11:28 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Shows the user's own pull request under Mergen as soon as the branch protection of its base lets the user merge it; with a hint to rebase when main moved on.
See doc/prs.
🤖 Generated with Claude Code
🟡 werkrevisor YELLOW for
6953cf7, superseded by the result for38b5560🟡 werkrevisor: YELLOW / HUMAN_REVIEW
Change kind:
feature_with_tests.Reasons
Findings
Doc example contradicts test fixture at
doc/prs/2026-10-20-PR#94-own-pr-merge.md:13, severity unknown, counted as medium, hint, as a line commentAwkward phrasing in Open Questions at
doc/prs/2026-10-20-PR#94-own-pr-merge.md:108-111, severity unknown, counted as medium, hint, as a line commentClassifier
10 of 11 units passed all questions (1 PR document(s)).
Usage: model `openrouter/minimax/minimax-m3`, LLM done, tokens counted before the call 36759, calls 1, tokens in 35572 / out 22627 (reasoning included in out), duration 303.6 s, cost 0.0378 USD (reported), classifier `jev-1.13.0` calls 11, tokens in 9069, cost 0.0004 USD, finding judge `jev-1.13.0` calls 2, tokens in 3909, cost 0.0002 USD, build file judge `jev-1.13.0` calls 3, tokens in 7105, cost 0.0003 USD, phases: path_judge 0.4 s, classifier 0.7 s, context 1.4 s, model_review 300.5 s, finding_judge 0.3 s, config: defaults + host + repository (.werkrevisor.toml at main1 answer ignored because of a confidence below [classifier] min_confidence.
ec7c982).Reviewed head `6953cf7d7e706de04b7aadf27b86b92b1e1587bd` against base `ec7c982bf0ff8251261a1f350ac4ab213d837abb`, werkrevisor 0.52.0.
werkrevisor: YELLOW / HUMAN_REVIEW for
6953cf7d7e706de04b7aadf27b86b92b1e1587bd.The result comment of werkrevisor holds the details.
@@ -0,0 +10,4 @@"Du bist dran" shows the user's own pull request as Mergen only when another human approved it.The branch protection of the base branch decides what a merge needs, not werkregie:e.g. `mi/werkdock` needs no approval and only the check `werkator`,Doc example contradicts test fixture, severity unknown, counted as medium (werkrevisor)
hint; Jev: real 0.81, severity 1.3 of 3
The Problem section says "e.g.
mi/werkdockneeds no approval and only the checkwerkator", but the integration test fixture inGiteaSourceFetchTestconfiguresmi/werkdock'smainwithrequired_approvals: 1(andstatus_check_contexts: ["werkator"]). The Scenario#94.02 prose, naming this property for "werkdock", and the matchingGiteaSourceTest(Protection(0, ["werkator"])namedwerkdock) use the same example name with a 0-approval protection. The behaviour tested is correct; only the narrative example is out of sync with the integration fixture for the same repo, which a reader verifying the doc against the test would notice.Fixed in
38b5560: the fetch test usesmi/werkbaumwith 1 approval;werkdockstays the example of no approval.@@ -0,0 +105,4 @@## Open Questions- [x] Which pull requests are the user's own?Awkward phrasing in Open Questions, severity unknown, counted as medium (werkrevisor)
hint; Jev: real 0.75, severity 1.0 of 3
The Open-Questions item reads "Each other one counts as an agent's, also that of a colleague; this PR does not change that." The phrase "an agent's" is incomplete (a noun is missing, likely "as an agent's pull request" or similar) and "that of a colleague" reads as a stray reference. The meaning can be guessed, but the sentence as written is unclear.
Fixed in
38b5560: "werkregie treats every other pull request as an agent's pull request, also one of a colleague".🟢 werkrevisor: GREEN / PASS
Change kind:
feature_with_tests.Reasons
Findings
Documentation Mismatch at
dashboard/README.md:298-300, severity unknown, counted as mediumhint; Jev: real 0.85, severity 2.3 of 3
The README's new Mergen description states "in each case no automerge scheduled", claiming this universal qualifier for the protected-own-PR, unprotected-own-PR, and foreign-PR cases. However, the code path for the unprotected-own-PR case in
ownReviewFlags(whenpr.protection == nulland another human approved) does not checkpr.automerge. Concretely: a user's own pull request on an unprotected branch, approved by another human, with Gitea's automerge scheduled, will still receive amergeflag and the "approved von …" text — contradicting the documented universal behavior. The PR document's Scenario#94.05 says "as before" for the unprotected case, confirming the code's behavior was intentionally left unchanged; the README update overstates what the code does. Either the README should restrict the qualifier to the protected and foreign cases, orownReviewFlagsshould skip a turn with!pr.automerge.Classifier
11 of 11 units passed all questions (1 PR document(s)).
Usage: model `openrouter/minimax/minimax-m3`, LLM done, tokens counted before the call 36784, calls 1, tokens in 35593 / out 34656 (reasoning included in out), duration 437.0 s, cost 0.0522 USD (reported), classifier `jev-1.13.0` calls 11, tokens in 9085, cost 0.0004 USD, finding judge `jev-1.13.0` calls 1, tokens in 2992, cost 0.0001 USD, build file judge `jev-1.13.0` calls 3, tokens in 7105, cost 0.0003 USD, phases: path_judge 0.2 s, classifier 0.8 s, context 0.2 s, model_review 435.1 s, finding_judge 0.2 s, config: defaults + host + repository (.werkrevisor.toml at main2 answers ignored because of a confidence below [classifier] min_confidence.
ec7c982).Reviewed head `38b5560a7a2d3a23909a51d8f866abda8d2c995b` against base `ec7c982bf0ff8251261a1f350ac4ab213d837abb`, werkrevisor 0.52.0.
werkrevisor: GREEN / PASS for
38b5560a7a2d3a23909a51d8f866abda8d2c995b.The result comment of werkrevisor holds the details.