A complete review.
Outside your coding agent.
Doomer independently investigates the change, its requirements, and the surrounding code. Your team gets a review with findings, evidence, and a recorded revision to inspect in GitHub and in Doomer.
Start the investigation with your coding agent or on GitHub. It can finish before CI checks and within minutes of opening the PR.
Reviews / billing-service / PR #42
Add invoice exports for account admins
Completed in 3m 35s · revision a4b8e12
Review complete
Review summary
The investigation, evidence, and execution history stay with this revision.
Prepare source
Complete
Build context
Complete
Select reviewers
Complete
Prepare reviewers
Complete
Review changes
Complete
Verify & publish
Complete
Reviewer execution trace
From pull request to an informed merge decision.
The review runs as a separate investigation, with its own findings and evidence. You can inspect it without reopening a coding-agent chat.
1. Connect and open a PR
Choose repositories for the GitHub App. Eligible pull requests start a review against the recorded commit.
2. Examine and resolve
Inspect findings, code references, intent, and evidence. Push a fix and review the updated change.
3. Approve with evidence
Use the review and GitHub checks in your approval process. Configure approval and merge automation separately.
Findings where your team reviews code.
Inline comments connect a concern to the changed line, the evidence, and the correction. Your team can discuss and resolve them on the pull request.
Add invoice exports for account admins
routes/invoice-export.ts
+ router.get('/accounts/:accountId/invoices', requireAdmin, async (req, res) => {+ const invoices = await loadInvoices(req.params.accountId) res.json(invoices)Check access to the requested account before loading invoices.
An admin of account A can supply account B’s ID here. The middleware verifies the admin role, but the related permission code does not establish membership in the requested account.
await requireAccountAccess(session.user.id, req.params.accountId)Verified against this revision and the shared admin middleware.
Show author response
Added the account access check and a regression test for cross-account export requests. Ready for another review.
Make the review part of your change-control process.
Explicit repository access, commit-specific findings, and configured GitHub checks support a reviewable approval process.
Approve repository access
Choose which repositories Doomer can analyze and who can configure them.
Keep evidence with the change
Review the recorded revision, findings, and responses alongside the pull request.
Control approval separately
Configure approval automation and required checks to match your team’s policies.
Your organization determines how these records support its SOC 2 change-management controls.
Code can be correct in isolation and still miss the point.
A helper can pass its tests while a caller breaks. An implementation can be internally consistent while leaving out an acceptance criterion. Deep review connects those pieces.
investigationTrace · challenge · verify
Impact & uncertainty
The change and its surroundings
The recorded base and head commits, related code, callers, and tests. The pull request title and description explain what the author set out to change.
The work behind the code
Linked issues and documents bring requirements, acceptance criteria, and design decisions into the investigation. Configured searches can suggest related work when a PR has no linked issue.
What your team already knows
Repository history and relevant feedback from earlier reviews preserve decisions and disagreements. For mapped Sentry projects, recorded errors add stack locations and release or environment context.
Your clarifications
Add the expected behavior when a requirement is missing or ambiguous. With intent capture enabled, saved clarifications help the next review examine the change against the goal.
Follow the risk through the code.
Use specialized adversaries to investigate security, reliability, and product behavior. They examine the change and its relationships with surrounding code, looking for concrete paths to a failure.
- Entry pointAccount ID in a request
A caller chooses which account to export.
- Application pathExport handler
The identifier reaches the invoice query.
- Missing boundaryOwnership check
A finding identifies an authorization gap.
- Possible impactAnother account’s invoices
The path explains how data could be exposed.
An attack-path brief connects the entry point, affected code, and possible impact to its supporting finding. It also identifies assumptions that still need verification.
Attack paths appear when a completed review produces a brief. Each investigation runs against the recorded revision, so the evidence relates to the code that was actually reviewed.
Enough detail to make the next decision.
Follow findings back to the relevant code and attack paths. Read the reasoning, inspect the sources, and decide what needs a fix or a closer look.
18const accountId = request.params.accountId
19const invoices = await db.invoice.findMany({
20 where: { accountId }
21})Findings
Concerns and supporting evidence, including findings below your GitHub posting threshold.
Intent & sources
The interpreted goal, linked requirements, suggested work, and retrieval gaps.
Attack paths
Connections between an entry point, the affected components, and possible impact.
Code provenance
Recorded coding-agent and model attribution when Git AI notes are available. Missing notes remain unknown.
In GitHub and on the review page.
Changed-line findings appear on the diff. Other findings appear in the review body. The review page brings the investigation together so your team can inspect context and evidence alongside the results.
Choose standard, adversarial, or combined review tracks. Configure posting thresholds and comment voice for your repository, and use review replies to capture your team’s feedback.
A failed review is reported as a failure. Approval and merge automation are separately configured through Stampy Stamp.
Review configuration →Start before the handoff. Review again as the change evolves.
Catch more before your team picks up the PR.
Bring requirements, adversarial investigation, and code evidence into the review. Keep human attention on the decisions that need it.
Verify access before exporting.
The query uses the account from the request. Check that the signed-in user can access that account before returning its invoices.