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

# Review Changes

> Understand when and why ByteRover flags context changes for your review

ByteRover writes changes to your context tree immediately when you curate. Most changes apply silently, but some are flagged for review — giving you the chance to approve or roll back before the changes are pushed to your team.

## When does a review trigger?

ByteRover evaluates every curation operation and flags it for review based on two criteria:

| Condition              | Review required | Why                                                                                                 |
| ---------------------- | :-------------: | --------------------------------------------------------------------------------------------------- |
| **DELETE** operation   |      Always     | Deletions are irreversible — removing knowledge should be intentional.                              |
| **High-impact** change |      Always     | Changes that alter core decisions, contradict existing knowledge, or shift architectural direction. |
| Low-impact change      |        No       | Minor additions, clarifications, or supplementary details apply automatically.                      |

The curation agent determines impact level for each operation. A high-impact change is one that would meaningfully alter the meaning or direction of your stored knowledge — for example, replacing "we use Redis for caching" with "we use Memcache for caching."

<Note>
  Changes flagged for review are already written to disk. Review lets you **keep or roll back** the change — it does not block the write.
</Note>

## What gets flagged

Any of the five curation operations can trigger a review:

* **DELETE** — Always flagged, whether deleting a single file or an entire domain folder.
* **UPDATE / UPSERT** — Flagged when the change is high-impact (e.g., changing core technology, contradicting previous knowledge).
* **MERGE** — Flagged when combining files involves high-impact content changes.
* **ADD** — Rarely flagged, since new knowledge typically doesn't conflict with existing content.

## Review lifecycle

```
brv curate "..."
    │
    ▼
Curation agent processes operations
    │
    ├── Low impact ──► Applied silently
    │
    └── High impact / DELETE ──► Applied + flagged for review
                                      │
                                      ▼
                              Pending review
                              (visible in CLI, TUI, and web UI)
                                      │
                        ┌─────────────┴─────────────┐
                        ▼                           ▼
                   Approve                       Reject
                (keep changes)           (restore from backup)
```

When a review is pending:

* **The change is live locally.** Your context tree already reflects the new content. Queries return the updated knowledge.
* **The change is blocked from push.** Files with pending or rejected reviews are excluded from `brv push` until resolved.
* **A backup exists.** ByteRover stores the pre-change version so it can restore the file if you reject.

## How you're notified

Where you see pending reviews depends on how the curation was triggered:

| Method                            | Notification                                                                                                |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| `brv curate` (CLI, no `--detach`) | Review summary printed directly in the command output                                                       |
| `brv curate --detach`             | No inline notification — use `brv review pending` to check                                                  |
| `/curate` (TUI)                   | TUI status shows pending review count and a link to the [Changes tab](/local-web-ui/changes) in `brv webui` |
| Via coding agent (MCP)            | The agent receives the review summary in the tool response                                                  |

Whichever path triggered the curate, pending edits also show up inline in the [Changes tab](/local-web-ui/changes#reviewing-agent-edits) of `brv webui` (when running), with op-type and impact badges next to your other diffs. Dashboard notifications deep-link to that tab with the right project pre-selected.

## What happens on approve vs reject

| Action      | Effect                                                                                                         |
| ----------- | -------------------------------------------------------------------------------------------------------------- |
| **Approve** | The current file content becomes the new baseline. The backup is deleted. The file is eligible for `brv push`. |
| **Reject**  | The file is restored from the pre-change backup. The backup is deleted. The change is discarded.               |

For **DELETE** rejections, the deleted files are restored to disk. For **MERGE** rejections, both the target file and the deleted source file are restored.

## Next steps

<CardGroup cols={2}>
  <Card title="Manage Reviews" icon="list-check" href="/review/manage-reviews">
    Approve, reject, or selectively review changes via CLI and web UI
  </Card>

  <Card title="Agent Review Workflow" icon="bot" href="/review/agent-workflow">
    How coding agents discover and handle reviews on your behalf
  </Card>
</CardGroup>