Review feedback

Doomer keeps feedback on its own review comments and uses that memory on later reviews of the same repository. The memory survives ephemeral CI runners. Collection is automatic. There is no separate “enable memory” switch.

Review feedback (/team/<namespace>/review-feedback) is visible even when hosted inference is off, because self-managed CI can register the same kind of feedback. Members can inspect it. Owners and admins can change whether an event is used.

What becomes memory

After a review posts inline findings, Doomer watches that pull request. For hosted reviews the worker registers the posted comments. For self-managed CI, the runner registers them with a repository-bound token. A service account can pull and run packages, but it cannot register that repository-bound memory. Use OIDC for CI if you want CI reviews to contribute.

The watcher reads human replies and thumbs-up or thumbs-down reactions on those findings. Bots are excluded. Neutral conversation does not create memory. The phrase ok doomer does not create memory.

Useful events contribute immediately:

• An explained reply is classified. Its weight follows how confident that classification is about the interpretation, not about whether the human is correct.
• A reaction, an unexplained disagreement, or a resolved conversation that qualifies (below) has weight 0.25 and applies to that exact finding. It does not invent a technical rule.
• Comment feedback is organization scope unless the reply is about specific code, a guarantee, or a convention in that repository. Organization scope means the same Doomer project and the same GitHub repository owner. It does not cross projects or owners. Repository scope reaches only the repository it came from.

Each person contributes at most one unit per topic, across both agreement and disagreement. Repeating a comment or reaction does not raise that cap. Conflicting feedback weakens the adjustment and both sides are kept.

The reviewer sees bounded memory as untrusted evidence. It matches the technical condition to the current code, adjusts confidence, and drops findings that fall to low confidence. It does not suppress a whole category because one reply disagreed.

A lone thumbs-down is weaker than an explained disagreement. One explained negative of full weight is stronger than a reaction. An equally strong agree and disagree cancel. These are evidence weights, not probabilities.

Kinds of comment

The classifier records why the human replied, separate from agree or disagree:

The kind describes the human’s claim. It is not verified truth. Kind does not by itself change the weight, widen the scope, or create an exception that mutes a class of findings. A local convention is advisory evidence, including on deprecation findings.

Acknowledgement

The first time a comment is recorded, Doomer replies once in that thread. The reply confirms receipt. It does not say the commenter is correct, and it does not promise to suppress or fix the finding. Reactions are silent. If a generated acknowledgement is unavailable, the reply is “Got it — thanks for the feedback!”.

Disagreement resolves the thread

A human with write, maintain, or admin on the repository can dismiss the bound Doomer conversation by a reply classified as disagreement or by a thumbs-down. Agreement, neutral replies, and bot feedback do not resolve the thread. Feedback from other people still enters memory, but it cannot dismiss the thread.

Doomer checks that it owns the root comment, that the disagreement is unchanged, and that the pull request is still open on the watched head. Only that conversation is resolved. The same reply or reaction does not resolve the thread again if someone reopens it. A later edit is reclassified. A failed resolve is retried on a later poll.

Resolving the thread emits GitHub’s review-thread event and lets Stampy Stamp look at the pull request again. Stampy still needs every conversation resolved and an approval mode that allows the change. Merge still needs the merge setting and GitHub’s merge checks. Automatic resolution can therefore lead to approval and merge. It does not assert that the finding was wrong.

The installation needs Contents write for that resolution. Until an existing installation approves it, disagreement is still stored, and the check can report that conversations could not be updated.

Resolving a conversation without a reply

A human resolving a bound conversation starts a provisional event. Doomer waits about ten minutes from when it first sees the resolution.

• If the reviewed code is unchanged, or a complete comparison shows only unrelated edits, the event then contributes weight 0.25 of repository-scoped negative evidence for that exact finding. It supplies no invented reason. The same person’s reactions share the per-topic cap.
• Changes to the reviewed lines, removal or rename of the reviewed file, or a confidently related helper change make the resolution neutral. A push by itself is not proof the finding was addressed.
• Same-file edits outside the reviewed lines, and edits in other files, are assessed for relevance.
• A missing, ambiguous, force-pushed, truncated, or oversized comparison leaves the resolution pending and does not add negative evidence.

Doomer keeps watching. A related push later retracts the implicit negative on a following poll. Once a related change is seen, the neutral state stays until the conversation is reopened. Reopening clears the implicit feedback. Explicit comments and reactions are not removed by the resolution event. Resolution feedback does not add a reply.

This needs Contents read as well as pull request access. Open pull requests are polled about every five minutes. Closed pull requests are revisited about daily, so a correction there can take up to a day. A push between polls can briefly be ahead of the retraction.

Manage what is used

The Review feedback table groups events by repository, scope, package, rule, and topic (or the original finding when there is no topic). Counts include replies, reactions, and resolutions. Search covers feedback text, findings, authors, repository, rule, and path before pagination. Filter by repository, by Influencing or Not influencing, and sort by recency or count.

Open a topic for the individual events. Each event shows the GitHub source, author, kind, scope, evidence weight, rule, path, and whether it supports or disputes the finding.

Contributing means the source is still active, the status is Active, the classification is agreement or disagreement, and the weight is not zero. Mixed topics contain both contributing and excluded events. These labels mean eligible to be loaded, not a measured effect on a future review.

Owners and admins set:

• Active — eligible again. This does not restore a deleted GitHub reply or reaction, and it does not bypass classification.
• Disabled — stop using this event.
• Overturned — the claim is no longer correct.

A written reason is required (up to 2,000 characters). The latest ten status changes are shown with the actor and the reason. Saving the same status again does not add another history row.

Disabled and overturned events are left out of memory for both CI and hosted reviews. They also do not trigger a new acknowledgement or a disagreement resolution on a later poll. A review that already loaded the old memory is not rewritten.

GitHub edits and deletions are separate from this status. An edited reply is reclassified. A deleted reply or removed reaction stops contributing once a complete snapshot is reconciled. The status you set is kept across those polls.

What memory is not

There is no memory approval queue, no manual undo of a single reaction beyond Disabled or Overturned, and no retraining step on this page. Promoting a piece of feedback into a portable exception, and training a customer model from it, are not part of this screen. Custom training does not run from these events today.

Hosted reviews receive the project’s memory directly. The database credential is not passed into the review command. The memory file has to match the repository being reviewed.