doomer / ai
DocsSign In

Intent and provenance

What a hosted review used: inferred intent, tracker sources, code provenance, and the evidence on the review page.

Intent and provenance

A hosted review page separates three kinds of evidence: what the change was supposed to do, which sources that came from, and who or what authored the code when that was recorded.

The project page is /review/<project>/<owner>/<repo>/<number>.

Intent

When intent capture is enabled, each hosted review refreshes one saved snapshot for that pull request. The snapshot is tied to the project, repository, and pull request. One snapshot is updated across commits. Another project that can see a shared run trace does not see this snapshot.

The worker asks the app for linked issues using the project’s tracker mappings and credentials, and only while that exact review job is running on that head. The packet is limited and attributed to its sources. Failed fetches stay visible as source gaps and do not block code review. A pull request with no linked issue still uses its title and description.

Before the code review runs, Doomer infers a short purpose and the constraints it can support from the pull request, linked sources, and comments in the changed code. The Intent section shows that synthesis first. The full pull request description stays under source evidence. The page refreshes while the review is active, so the intent can appear before the rest of the review finishes.

Source documents stay labeled as source text. They are not an approved statement of intent.

Clarifications

Clarify the intent accepts missing requirements, constraints, or expected behavior, up to 4,000 characters. Saving a clarification does not by itself rerun the review.

Review updated intent

Review updated intent is offered when intent capture is on, the saved snapshot is for the same head as the review, and the saved intent differs from the intent that review used. It is offered for a completed review, and for a failed or cancelled attempt that is still showing the previous delivered result.

The action refreshes sources again, checks that the pull request head still matches the hosted job, and queues a review only if the saved intent differs. Repeating it for the same packet does not queue another run.

While a rerun is queued or failing, the page keeps the last delivered findings. Those findings are replaced only after the new review completes.

When intent capture is off

Intent capture is a deployment switch, not a project setting. When it is off:

  • Review updated intent is hidden.
  • Clarifications can still be saved. The form says Doomer does not use them in reviews yet.
  • Issue source mappings can still be prepared and refreshed.
  • Code review runs without the intent packet.

You cannot turn this on from Issue sources or Repos.

Sources and attribution

Sources lists linked issues with provider, key, title, fetch time, and a link to the original. Description, discussion, tasks, related work, and parent or child items open from that card. Related items say whether they are Linked in the tracker or Suggested by search. Search suggestions are context, not requirements for this pull request.

Issue search and coverage lists each mapped tracker, whether search is configured, and candidates retrieved for an unlinked pull request. If no tracker is mapped, the page says the review uses pull request and code evidence.

Source gaps list what could not be fetched. A stale banner means mappings or credentials changed after the snapshot. Choose refresh to load the current context. Refreshing unchanged content keeps the same revision number.

Story alignment, when the review produced it, uses the labels Appears aligned, Possible gap, Clear mismatch, and Unclear. Alignment is a comparison of linked story text with the diff. It is not a merge decision.

Code provenance

Code provenance is optional and separate from intent. It reads Git AI notes from refs/notes/ai for commits in the pull request. The page shows how many commits had a readable note and up to five agent and model pairs, with a count of any further pairs.

Missing notes mean provenance is unknown, not that a human wrote the commit. Unreadable notes are counted and do not invent an agent. A summary from an earlier commit is identified as stale. A temporary failure says provenance is unavailable and the review itself is unchanged.

Provenance does not change reviewer routing, checks, or Stampy. Provenance is captured automatically with review context; there is no separate manual refresh action.

Limits:

  • The App installation needs Contents read. Older installations may need to approve that permission.
  • Pull requests with more than 100 commits are reviewed without a provenance summary.
  • A normal branch push does not publish refs/notes/ai. Push that ref from the checkout that recorded the notes. Do not force-push it if the remote moved; synchronize and push again.

The public review URL (/review/<team>/<owner>/<repo>/<number>) omits the provenance section. Use the project review page to see it.

Attack paths and impact

Attack paths are briefs built from findings: entry, path, possible impact, the finding used as evidence, and what is still uncertain. They appear after a completed review when that brief exists. No path does not mean the change is safe. When Doomer checked findings against the diff, the page says so.

Impact uses the experimental service map for the repository. The worker builds a proposed map of services, jobs, and libraries for enabled repositories, including a backfill, and refreshes the default branch about daily. Service maps in the project sidebar lists components, proposed code roots, and the manifest files used. A changed path that matches a root is possible impact, not proof of a runtime change. Unmapped files and unavailable maps stay visible. This context does not change routing, the check, or approval.

What a review used

Read the page in this order when you need to defend a comment:

  1. Intent — the purpose and constraints Doomer inferred, plus any clarification your team saved.
  2. Sources — the issue text and whether a story was linked, suggested, or used as inferred context.
  3. Findings — the comment body, file, and whether it was posted or withheld by the posting threshold.
  4. Attack paths — the evidence and the uncertainty attached to a finding.
  5. Provenance — agent and model notes, if any were pushed. Absence is unknown, not a negative attribution.
  6. Stampy decisions, when approval was evaluated. See Stampy Stamp.