Settled decisions

When WuMing raises a finding, you can settle it with a single reply. Settled decisions are remembered across pull requests: the same class of finding is not raised again on the next PR that touches the same code, so you explain a trade-off once instead of once per review.

Quick reference

Variable	Default	Purpose
WUMING_LEDGER	true	Enable/disable the ledger
WUMING_LEDGER_ISSUE	(unset)	Pin the ledger issue number
WUMING_BOT_LOGIN	(unset)	Pin the bot identity
WUMING_SETTLE_AUTHORS	(unset)	Logins trusted to settle findings without endpoint verification

Settling a finding

Reply to the finding on the pull request with a marker line as the first line of your reply, followed by your reason:

wuming: declined — debug logging is intentional here and documented in the README

wuming: resolved with option 2 — go with the router-based approach

Both forms settle the finding; the difference is only the label stored with the decision. The reason is recorded verbatim, so write it for your future self.

Replies are recognised in two ways:

• Threaded replies — use your forge's reply control directly under the finding. This is always attributed precisely.
• Plain comments — a marker posted anywhere on the PR conversation is also harvested when it is unambiguous: the PR has exactly one open finding, you name the path in the marker (wuming: declined docs/api.md — the trailing slash is intentional), or you quote the finding's hash prefix (wuming: declined 105f73a — asked for in #62). The prefix attributes the finding whose wuming:sha256 marker starts with it — useful when two findings share a path, and the natural form for automation accounts, which can read the hashes straight from the review comments via the API and cannot thread replies on Forgejo. Quote at least 7 characters, like a git short hash.

Anything ambiguous is skipped and logged rather than guessed: if two open findings could match, thread the reply, name the path, or quote a longer prefix.

Only the repository owner, users with write access, and logins listed in WUMING_SETTLE_AUTHORS can settle findings.

Trusting an account that also writes code

Granting settle authority to an automation account (for example, the agent that posts your review comments) means a compromised or manipulated run could settle its own findings and suppress them permanently. That is an accepted trade-off when the account already holds repository write access — but grant the list deliberately, and prefer accounts whose reviews you independently trust.

Where decisions live

WuMing stores each decision as a comment on a dedicated issue in your repository, titled WuMing: settled decisions and labelled wuming-ledger. The issue is created automatically on first use and is created closed — it never appears in your open-issue counts. WuMing only ever writes into an issue it created itself; if you label one of your own issues with wuming-ledger, it is ignored.

Each record keeps the finding's hash, the file and line, your reason, and a link back to the PR where the decision was made.

How reviews respect the ledger

Suppression works on two levels:

• Exact repeats — a finding whose hash matches a settled record is dropped before it is ever posted. This is mechanical; no model judgement involved.
• Near-identical equivalents — the review agents receive the settled decisions as context and are instructed not to re-raise them unless a code change genuinely makes the settled decision unsafe. This tier is deliberate: refactors move lines, and the hash of the same underlying complaint changes with them.

WuMing also sweeps recently active pull requests (open PRs and PRs merged within the last 60 days) on every run, so a decision you post after a PR's final review wave is still picked up.

Decline, don't fix

When a finding is a judgement call rather than a defect, settling it is cheaper than fixing it: a fix has to be reviewed again, a settled decision never comes back. Reserve declines for genuine trade-offs and record the reason — the ledger is only as useful as the reasoning it preserves.

Forgejo Actions note

On Forgejo/GitHub Actions the review token may have no backing user, in which case WuMing falls back to recognising itself as forgejo-actions. Set WUMING_BOT_LOGIN to pin the bot identity explicitly if your deployment differs.

Configuration

Variable	Default	Purpose
WUMING_LEDGER	true	Set to false to disable the ledger entirely
WUMING_LEDGER_ISSUE	(unset)	Pin the ledger issue number instead of auto-discovery — only point this at an issue you designate as the ledger
WUMING_BOT_LOGIN	(unset)	Pin the bot identity (see the Actions note above)
WUMING_SETTLE_AUTHORS	(unset)	Comma-separated logins trusted to settle findings without endpoint verification

The ledger is fail-open: if it cannot be reached, reviews run without it and the skip is logged. WUMING_DRY_RUN never writes to it.

For the full list of configuration variables, see the configuration reference.