> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Catch a Risky Pull Request with Review

> Watch Review flag a pull request that would break production, question its findings, and land the fix before the change merges.

A pull request looks small, but it would break the running release the moment it deploys. This walkthrough shows Review catching it, how you check the finding, and how the fix lands before anyone merges.

## The scenario

A developer opens a pull request that renames the `orders.status` column to `orders.state` and updates the new code to match. Tests pass. The version running in production still reads `orders.status`, so during the rollout every checkout on old pods would fail. The same pull request also adds an admin endpoint without the shared permission check your other handlers use.

## Prerequisites

* Review set up on the repository, with a connected Git provider such as GitHub, GitLab, or Bitbucket. See [Set up Review](https://docs.cloudthinker.io/guide/code-review/setup.md).
* Optional: a `CONVENTIONS.md` or `AGENTS.md` in the repository, so Review knows your team's patterns. See [What Review reads](https://docs.cloudthinker.io/guide/code-review/overview.md#what-review-reads).

## Walkthrough

**1. Open the pull request**

Open the pull request as usual, marked ready for review. Review skips drafts until they're ready. Nobody needs to start it.

**What you should see:** once the review finishes, a summary comment from `@cloudthinker-ai` on the pull request, plus inline comments on the lines it flags.

**2. Read the findings**

The migration gets a High finding in the deploy, migration, and backward compatibility category: the old release still reads `orders.status`. The new endpoint gets a Security finding for the missing permission check. Each finding carries a suggested fix.

**What you should see:** the verdict **Changes requested**, because at least one Critical or High finding is unresolved. Your provider's branch rules still decide whether the pull request can merge.

**3. Open the review in CloudThinker**

Go to **Review → Reviews**. The pull request sits on the **Needs attention** tab. Open it and read the **Walkthrough** on the **Overview** tab, then the cards on the **Findings** tab.

**4. Question the riskiest finding**

Reply in the migration finding's thread on the pull request:

```text theme={null}
@cloudthinker-ai Which code in the current release reads orders.status, and what is a safe order to ship this rename?
```

**What you should see:** a reply that names the files that still read the column and suggests a sequence, such as adding the new column first and dropping the old one in a later release.

**5. Push back where the code is intentional**

If a finding is wrong, reply in its thread with your reason. No mention is needed:

```text theme={null}
This endpoint is only reachable from the internal network, and the gateway enforces admin access.
```

CloudThinker re-checks the finding against the code and your reply. It withdraws the finding, acknowledges it, or keeps it open and says why. See [Push back on a finding](https://docs.cloudthinker.io/guide/code-review/mention-commands.md#push-back-on-a-finding).

**6. Land the fix**

On the finding card in CloudThinker, click **Apply fix** to commit the suggested change, or **Copy prompt** to hand it to your own coding agent. On GitHub or GitLab, to review the fixes in their own pull request first, comment:

```text theme={null}
@cloudthinker-ai autofix stacked
```

**Fix all findings** in the review header commits every fix to the source branch at once. Your click is the approval: fix commits from **Apply fix** and **Fix all findings** don't go through [Approvals](https://docs.cloudthinker.io/guide/approvals/overview.md).

**7. Push and get the re-review**

Push your changes. Review reads only the new commits and checks whether the earlier findings were fixed.

**What you should see:** fixed findings move to **Resolved**, and the verdict changes to **Approved** once nothing is left unresolved. The pull request moves to the **Ready to merge** tab.

## What made this work

* **Review read beyond the diff.** It compared the change with code the running release still uses, which tests on the new code alone can't show. See [What it checks](https://docs.cloudthinker.io/guide/code-review/overview.md#what-it-checks).
* **Conventions set the bar.** The shared permission check was a pattern your repository already follows, so a handler that skipped it stood out.
* **You could argue with it.** [Mention commands](https://docs.cloudthinker.io/guide/code-review/mention-commands.md) let you ask why, push back, and get a re-check in the same thread.
* **Votes shape later reviews.** A thumbs-down with a note on a wrong finding keeps later reviews of the repository from raising it again on unchanged code. See [Review workspace](https://docs.cloudthinker.io/guide/code-review/review-workspace.md#work-the-findings).

## Next steps

> **[Review workspace](https://docs.cloudthinker.io/guide/code-review/review-workspace.md)**
>
> Triage reviews, settle findings, and merge from CloudThinker.

> **[Mention commands](https://docs.cloudthinker.io/guide/code-review/mention-commands.md)**
>
> Every `@cloudthinker-ai` command and where each provider supports it.

> **[Learnings](https://docs.cloudthinker.io/guide/code-review/convention-rules.md)**
>
> Turn resolved findings into patterns that future reviews apply.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.