werkrevisor/config/werkbaum.toml

# werkrevisor host config for reviewing werkbaum (mi/werkbaum) on git.javagil.de.
# It is complete, so the review works without a .werkrevisor.toml in werkbaum; the PR never changes this file.

[model]
# An economy model suffices, since Jev decides and the model only advises (PR#40):
# on 4 heads with 10 known findings, MiniMax M3 found as many as Sonnet 5.5 for a tenth of the cost, but needs minutes.
id = "openrouter/minimax/minimax-m3"
# Operator-maintained prices in USD per 1M tokens.
input_price_usd_per_mtok = 0.30
output_price_usd_per_mtok = 1.20
# Longer prompts degrade the review even within the context window.
max_context_tokens = 150000
# Includes reasoning tokens; MiniMax M3 thinks up to 30000 tokens, a lower limit cut its answers.
max_output_tokens = 32000
# "low" and "none" missed a review on 1 of 4 heads each.
reasoning_effort = "medium"
# On 2026-10-08 some calls hung for over 700 s; the maker of the model first, others when it fails.
provider_order = ["minimax"]
# A call took up to 242 s; Werkator's ai-review build allows 15 minutes for 2 calls.
timeout_seconds = 300
max_retries = 1
# MiniMax reported at most 2 % more prompt tokens than o200k_base counted.
token_count_factor = 1.05

[budget]
# A review with 2 calls of 150000 input and 32000 output tokens costs at most about 0.17 USD.
max_usd_per_review = 0.20
min_key_remaining_usd = 0.50

[size]
# Changed lines and files outside the docs; above them a human looks at the PR (YELLOW).
max_changed_lines = 800
max_files = 30

[categories]
# A monorepo: the editor in plain JavaScript under frontend/, the Spring Boot backend under backend/.
docs = ["**/*.md", "docs/**"]
tests = ["frontend/tests/**", "backend/src/test/**"]
main = ["frontend/src/**", "frontend/index.html", "frontend/public/**", "backend/src/main/**"]
api_spec = ["backend/src/main/resources/openapi/**"]
auto_approvable = [
    "docs_only", "tests_only_added", "docs_and_tests", "refactoring", "feature_with_tests", "harmless_only",
    "mechanical_only", "mixed",
]

[hard_yellow]
# Only secrets stay hard.
paths = ["**/*secret*", "**/*.pem", "**/*.key", ".env*", ".envrc"]
# Jev judges the build, CI and publication files, and with [path_judge] scope = "all" every other file.
judged_paths = [
    ".gitea/**", ".github/**", ".werkator*", "scripts/**", "tools/**",
    "backend/build.gradle.kts", "backend/settings.gradle.kts", "backend/gradle/**",
    "frontend/package.json", "frontend/package-lock.json", "frontend/vite.config.js",
]
secret_scan = true
# Test data holds fake passwords; private keys and the real key formats stay flagged there too.
secret_scan_exclude = ["frontend/tests/**", "backend/src/test/**"]

[pr_doc]
# An open question in a changed PR document gives RED before any model call; TEMPLATE*.md and README.md never count.
globs = ["docs/prs/20*-PR#*.md"]
# The PR documents of werkbaum are German; see docs/prs/README.md there.
open_question_headings = ["Offene Fragen"]

[review]
extra_instructions = """
Write all findings in English.
werkbaum is a text notation for work breakdown structures with all-of and any-of decomposition,
an editor in plain JavaScript under frontend/ and a Spring Boot backend in Kotlin under backend/.
docs/SPEC.md defines the notation; AGENTS.md lists the rules, e.g. SPEC first, then code, then frontend/public/llms.md,
and a line in docs/CHANGELOG.md for each feature and fix; check each change against them.
The documentation and the PR documents are German.
Judge whether the PR document under docs/prs/ is clear, correct and consistent with the code.
werkrevisor itself checks line length, sentences per line and sentences per paragraph of the docs;
never report these rules, not even as a style remark.
A tool writes each section of a doc from a comment `<!-- generated by … -->` up to the next heading;
report nothing about such a section.
For documentation, report only bloated or mannered prose (filler, narration of the implementation),
unclear statements, and contradictions between the PR document and the code.
Report only concrete problems with a realistic impact.
The user prompt contains, after the diff, the full new content of every changed file except the documentation;
documentation appears only in the diff.
Check each changed line against constraints, invariants and conventions stated elsewhere in these files,
e.g. in header comments, and report a violation as a key issue.
Review the diff; use the full files only as context.
Start every issue_header with the severity of the issue: [high], [medium] or [low].
[high]: wrong behavior, data loss, a security problem or a broken contract in a realistic scenario.
[medium]: a defect with limited impact, or a missing test for changed behavior.
[low]: cosmetics, wording, log noise or style.
"""
max_findings = 3
# Without Jev, one high finding or this many medium findings give ORANGE, another medium finding YELLOW;
# with Jev, finding_real_min and finding_severity_min of the host config decide.
orange_min_medium = 2
# The complete new version of each changed file follows the diff in the prompt.
# 160000 chars are about 50000 of the 150000 input tokens, counted with token_count_factor = 1.05;
# a larger prompt gets excerpts instead, then the diff only.
full_files = true
max_full_file_chars = 80000
max_full_files_chars = 160000
# PR-Agent reads AGENTS.md from the default branch, never from the PR.
repo_context_files = ["AGENTS.md"]

[writing]
# docs/CHANGELOG.md holds one note per line, and docs/DECISIONS.md argues in long paragraphs;
# the shared limits of 128 characters and 5 sentences would flag nearly every change of them.
# A violation is a hint in the comment and never blocks; the model still reviews the PR.
enabled = true
max_line_length = 400
max_sentences_per_paragraph = 20
# Empty means the docs category.
globs = []

[mechanical]
# A changed file whose every changed line is an import, a whitespace change or a rename does not go to the model.
enabled = true
# Indentation or line breaks carry meaning in these files, so a whitespace change there is never mechanical.
whitespace_significant = ["*.py", "*.yml", "*.yaml", "Makefile", "makefile", "GNUmakefile", "*.mk", "*.md",
                          "*.haml", "*.pug", "*.coffee", "*.nim", "*.fs"]
# Built-in import rules exist for java, kt, kts, ts, tsx, js, jsx, mjs, go and rs.
# A [mechanical.imports] table adds or replaces the line regexes of a file extension; an empty list switches it off.

[gate]
# Branch protection requires one approval from {bot, human_reviewers}; see the README.
yellow_gate = "approval"
human_reviewers = ["mi"]
assessment_context = "ai-review/assessment"
# Only a PR whose title changed from "WIP: " to one without gets a review; the bot then schedules the merge,
# so a GREEN PR merges at once and a YELLOW or ORANGE one with the human approval.
require_wip_transition = true
automerge = true

[engine]
# "llm": the LLM review alone; "classifier": Jev alone, no LLM; "combined": Jev, then the LLM with Jev's hints.
mode = "combined"
# Jev decides with [path_judge] scope = "all"; the model only advises, so an economy model suffices.
model_role = "advises"

[classifier]
endpoint = "https://api.typesafe.ai/v1/systemone"
model = "jev-latest"
# Operator-maintained price in USD per 1M input tokens; Jev's output is free.
input_price_usd_per_mtok = 0.042
# Jev reads about 32000 tokens of state; a larger unit is not sent and makes the review YELLOW.
max_state_chars = 60000
max_units = 80
timeout_seconds = 20
pr_doc_globs = ["docs/prs/20*-PR#*.md"]
# Choice and score answers below this confidence do not count for the verdict; calibrate it with tools/jev-eval.
min_confidence = 0.3

# Every question asks for a problem: a value above red_above gives ORANGE, above yellow_above YELLOW.
# A score's criteria run from "no problem" to "worst problem"; its value is the normalized expected level.

[[classifier.scenario_questions]]
name = "hard_to_read"
type = "score"
instructions = """
`scenario` is a Gherkin scenario from a pull-request document; `feature` and `background` give its context.
Domain experts who do not program approve these scenarios as the specification.
How hard is the scenario to understand for such a domain expert?
The text may be German or English.
"""
criteria = [
    "A domain expert understands the scenario at the first reading.",
    "A domain expert understands it, but must read some steps twice.",
    "A domain expert needs a developer to explain parts of it.",
    "A domain expert cannot tell what the scenario requires.",
]
red_above = 0.75
yellow_above = 0.5

[[classifier.scenario_questions]]
name = "more_than_one_aspect"
type = "noul"
instructions = """
Does the Gherkin scenario in `scenario` specify more than one independent business rule or aspect,
so that it should be split into two or more scenarios?
Variants of the same rule that differ only in their data count as one aspect.
A second When with its own Then that checks a different case counts as a second aspect.
"""
red_above = 0.85
yellow_above = 0.6

[[classifier.scenario_questions]]
name = "implementation_details"
type = "noul"
instructions = """
Does the Gherkin scenario in `scenario` describe implementation details instead of business behaviour,
for example class, method, table or column names, SQL, internal HTTP headers or JSON internals?
Naming the public API endpoint, the HTTP method, the response status and the business fields
counts as observable behaviour, not as an implementation detail.
"""
red_above = 0.85
yellow_above = 0.6

[[classifier.scenario_questions]]
name = "given_when_then_misused"
type = "noul"
instructions = """
Does the Gherkin scenario in `scenario` misuse Given, When or Then?
Misuse is: an action or API call in Given, an expected result or check in When,
an action in Then, or a Then without a preceding When.
And-steps belong to the keyword above them.
"""
red_above = 0.85
yellow_above = 0.6

[[classifier.scenario_questions]]
name = "vague_then"
type = "noul"
instructions = """
Does a Then step of the Gherkin scenario in `scenario` lack a checkable outcome,
for example "works", "is handled correctly" or "behaves as expected",
without saying what an observer can check?
"""
red_above = 0.85
yellow_above = 0.6

[[classifier.section_questions]]
name = "hard_to_understand"
type = "score"
instructions = """
`section` is a section of a pull-request document that a human reviewer reads before the code.
How hard is the section to understand for a reviewer who knows the project but not this change?
Markdown lists, tables, links and code identifiers are normal here.
The text may be German or English.
"""
criteria = [
    "The reviewer understands the section at the first reading.",
    "The reviewer understands it, but must read some sentences twice.",
    "The reviewer must guess what some sentences mean.",
    "The reviewer cannot tell what the section says.",
]
red_above = 0.75
yellow_above = 0.5

[[classifier.section_questions]]
name = "slop"
type = "score"
instructions = """
How much of `section` is slop: filler words, mannered or promotional prose,
narration of the implementation instead of the reasons, or repetition of what other sentences already say?
Plain lists, tables, links and code identifiers are not slop.
The text may be German or English.
"""
criteria = [
    "No slop: every sentence carries information.",
    "A few filler words or one redundant sentence.",
    "Several sentences are filler, mannered prose, narration or repetition.",
    "The section is mostly filler, mannered prose, narration or repetition.",
]
red_above = 0.75
yellow_above = 0.5

[path_judge]
# Jev judges every changed file: only a change that touches security or weakens the checks waits for a human.
judge = "jev"
scope = "all"

[excerpt]
# An economy model selects the lines of an excerpt; on 4 measured heads it never found less than the fixed window.
select = "model"