Stampy Stamp
Stampy Stamp (/team/<namespace>/stampy-stamp) lets Doomer approve a pull request after a hosted review finishes and every review conversation is resolved. Merge is a second, independent choice.
The page is available when hosted inference is enabled. Owners and admins save it. The project default is Off, and Leave for manual merge. Turning a mode on does not approve reviews that already finished, and turning merge on does not merge pull requests that were already approved.
Only repositories with hosted reviews enabled are listed. Disabled repositories are hidden. Their saved approval and merge rules are kept for when you enable them again. A save rechecks GitHub access and that reviews are still enabled before it changes repository rules.
Project defaults
Which PRs can Doomer approve?
| Mode | Behavior |
|---|---|
| Off | No automatic approval from the default. An author or repository rule can still allow it. |
| Docs and non-code only | Approve when every changed path is documentation or a common image or PDF: .md, .rst, .adoc, .png, .jpg, .jpeg, .gif, .webp, .pdf. Any other extension blocks this mode. An empty file list is not approved. |
| Non-critical changes | Ask the project’s review model whether the diff changes critical behavior. Critical includes authentication, authorization, tenant isolation, secret handling, cryptography, billing, production deployment, data deletion or migration, security controls, and other behavior whose failure can expose data or broadly disrupt service. A sensitive filename alone does not block approval. Documentation, comments, tests, formatting, and behavior-preserving renames in a sensitive area are not automatically critical. If the diff does not show that a critical property was preserved, the change is treated as critical. |
| Any pull request | Approve a reviewed pull request, including changes in those areas, when the other gates below pass. |
What happens after approval?
- Leave for manual merge — approval only.
- Merge automatically — after approval, try to merge.
Each repository can inherit the project approval mode or set its own, and can separately inherit, enable, or disable merge. Approval can inherit the project default while merge is customized.
Author rules
Author exceptions on the project apply across repositories. A repository can add its own. Each rule is a GitHub username, including bot usernames such as dependabot[bot], plus:
- Approve — Use default, or one of the four modes.
- After approval — Use default, Leave for manual merge, or Merge automatically.
Use default keeps the next applicable setting. Each field resolves in this order:
- Repository author rule
- Project author rule
- Repository default
- Project default
Unmatched authors use the repository default, then the project default.
Doomer checks the pull request opener and every commit author and co-author GitHub reports, including Co-authored-by trailers. Everyone must qualify.
- The strictest approval mode wins. From strictest to loosest: Off, Docs and non-code only, Non-critical changes, Any pull request.
- Merge runs only when every author’s effective merge setting is on.
If any author rule exists, incomplete history, an unknown GitHub identity, a stale snapshot, or an author API error withholds both approval and merge. With no author rules, approval does not look up authors.
Example: project approval Off, and alice set to Any pull request plus automatic merge. Alice-only changes can be approved and merged. A co-author without their own allow rule keeps the project default of Off, so the pull request is not approved.
Gates before approval
A successfully completed hosted review can become an approval candidate. Partial or failed reviews never authorize approval or merge, even when completed reviewers found no issues. Stampy Stamp posts one comment per reviewed commit explaining the blocker and asking for a successful rerun. Before approving, Doomer checks the live pull request head, that it is not draft, the current settings, and every review conversation.
- Open conversations wait. Resolving a thread wakes the candidate. If that webhook is missed, Doomer retries. Retries back off and stop after 30 days or 50 attempts.
- Docs mode uses the file extensions above. Missing files never authorize an approval.
- Non-critical mode does not approve when the model is unavailable, the classification is uncertain, or the diff cannot be classified (including a diff over the size limit). Those failures do not count as “non-critical.”
- When non-critical mode blocks a clean review because the change was classified critical, Doomer posts one explanatory pull request comment for that reviewed commit. The comment is the model’s explanation of the changed behavior. Other modes, reviews that have findings, and temporary classification failures do not post this notice.
- Findings about a changed file that have no valid diff line are posted as file-level conversations. Resolve them on GitHub. Findings that remain in the general review body can be resolved individually in Doomer; each has a Resolve finding link.
- Merge conflicts block automatic approval and merge in every approval mode. Doomer also waits when GitHub has not finished checking for conflicts, then retries automatically. Mergeability is checked again immediately before approval or merge.
- The approval is pinned to the reviewed commit. Retries do not post a duplicate approval for that same decision.
Disagreement replies and thumbs-down reactions from people with write, maintain, or admin access can resolve the bound Doomer conversation. That wakes Stampy. Stampy still requires every conversation to be resolved and the approval mode to allow the change. Auto-resolution does not mean the finding was technically wrong. See Review feedback.
Merge on approval
Merge runs only when the effective merge setting is on, approval succeeded, and the repository’s approval mode is not Off. Doomer rechecks the policy, the reviewed base and head, and review threads, and merges that approved head.
- Every reported check run on that head must be success, neutral, or skipped.
- Every legacy commit status must succeed.
- This includes checks that branch protection does not require.
- Pending or unsuccessful CI is checked again about every five minutes. The existing approval is reused and does not spend the failure retry budget.
- GitHub still enforces repository merge rules. A refused merge is retried while the candidate is eligible.
- The method is a merge commit when GitHub allows it, otherwise squash, otherwise rebase.
The App needs Contents write, Checks read, and Commit statuses read. An installation that has not approved those permissions cannot merge. Approval posting has its own permission needs. Existing installations must accept the permission update GitHub shows.
How a decision is shown
Each finished evaluation is stored with the policy, outcome, reason, classifier explanation when there was one, whether the review was clean, the SHAs, and the time. The pull request review page and the run details show the latest 50 evaluations, including earlier commits.
The panel leads with the outcome, the behavior-based explanation, and the next action. Policy codes, timestamps, and commit hashes are under Decision details and history. A pending reevaluation is shown ahead of older decisions and the page refreshes. A review with no candidate says that no decision has been recorded. Older candidates from before this history existed show the saved outcome only. Doomer does not invent an explanation for them.
Understanding a withheld approval
A completed review can still be blocked from automatic approval. The Automatic approval tab shows unverified source requirements and findings posted in the general PR review. It also records the worker’s decision and explains the next action for live blockers such as unresolved conversations.
Findings below the repository’s GitHub feedback level remain visible in Doomer and do not independently block automatic approval. General review findings have a Resolve finding action in Doomer. People with write, maintain, or admin access to the GitHub repository can choose:
- Disagree — dismiss the finding for this review.
- Accept risk — acknowledge the concern and dismiss it for this review.
Push a fix to the PR to trigger the normal rereview. For a manual retry, use the PR-level rerun action or comment /doomer run on GitHub.
An optional explanation, the GitHub account, and the time are retained with each dismissal or reopening. Reopen finding restores the blocker. These decisions apply only to the exact reviewed diff, run, and finding; a new commit or rerun does not inherit a dismissal. A dismissal is a human decision, not evidence that the code was fixed or that the finding was technically wrong.
The Automatic approval tab lists remaining general findings with direct links. Dismissing or reopening a finding wakes Stampy Stamp automatically. Other conversations, unverified source requirements, approval policy, and merge checks still apply. An approval already published on GitHub remains in its history; reopening restores the blocker for subsequent automatic approval or merge checks.