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.

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 local review UI
Via coding agent (MCP)	The agent receives the review summary in the tool response

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

• Manage Reviews — Approve, reject, or selectively review changes via CLI and web UI

• Agent Review Workflow — How coding agents discover and handle reviews on your behalf