Skip to main content
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:
ConditionReview requiredWhy
DELETE operationAlwaysDeletions are irreversible — removing knowledge should be intentional.
High-impact changeAlwaysChanges that alter core decisions, contradict existing knowledge, or shift architectural direction.
Low-impact changeNoMinor 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.”
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:
MethodNotification
brv curate (CLI, no --detach)Review summary printed directly in the command output
brv curate --detachNo 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

ActionEffect
ApproveThe current file content becomes the new baseline. The backup is deleted. The file is eligible for brv push.
RejectThe 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