For Reviewers

Every project has a single review queue, shown at the top of the Build tab. Submissions appear in the order they arrive, tagged with the Developer's name, the session ID, the parent version, and the diff size. The queue is live — when a teammate hits Submit, your client receives the update over WebSocket and the row appears without a refresh.

• Filter by author, age, file path, or branch label.
• Pin urgent Submissions so they stay above newcomers.
• Claim a Submission to mark it "in review" — prevents two Reviewers double-handling the same diff.
• Submissions you claim sync to your sidebar across all your devices.

A Build is the unit that gets approved and promoted to a new Version. One or many Submissions can roll into a single Build — Reviewers decide which Submissions group together. This is how you ship a feature that took three Developers and seven sessions without seven separate Versions.

1. Open a Review Session from the queue. Velocity pulls every Submission you select into one in-RAM working copy.
2. Velocity computes the merged diff against the parent Version. Conflicts are surfaced inline using the same Loro CRDT engine that powers live sessions.
3. Run the project the same way a Developer would — Code tab, CLI tab, Compile if you need a local artifact.
4. When you're ready, hit Promote to Build. That bundles the selected Submissions into a single Build object and sends it to the Admin queue.

Every comment is anchored to a specific line range using Loro's position trackers, so comments survive rebases and reformats. Threads are real-time — the Developer who authored the line gets a notification the instant you start typing.

• Open a thread with Cmd+K on any selected range.
• Threads can be marked blocking — the Build cannot be promoted while a blocking thread is unresolved.
• Resolving a thread leaves a permanent audit record. Threads are never deleted, only closed.
• Quote-reply, react with the four monochrome reactions (ack / nack / question / thinking), or @mention to pull a Developer back into the session.

Before you open a Submission, Velocity can run the org's chosen CLI over the diff and show you a structured summary. Configure the default in Project Settings → Review → Pre-review CLI. Admins pick which CLI, which model, and whether the summary runs automatically or on demand.

• Plain-English changelog of what the diff actually does.
• Flagged risks: deleted exports, schema changes, new dependencies, regex changes, auth-adjacent edits.
• Suggested test paths the diff likely affects.
• The full CLI conversation is logged to Audit alongside the human review.

Approval is per-Build, not per-file. When you promote a Build, you're telling the Admin "these Submissions, taken together, are ready for sign-off." Rejecting works at the Submission level — you can bounce one Submission back to its author without killing the whole Build.

• Approve: the Build moves to the Admin queue with your name attached.
• Reject: the Submission returns to the Developer with your comments and a required reason.
• Request changes: the Submission stays in your queue but pings the Developer to push a follow-up.
• Every action — approve, reject, comment, edit, claim, release — is signed and written to the audit log.

Most reviews end at promote-to-Build. Some don't. Escalate when:

• The diff touches files in the project's Admin-locked path list (auth, billing, encryption, license code).
• Compliance scans surface high-severity findings you can't resolve yourself.
• A blocking thread reaches an impasse and you need a third opinion.
• The Developer is requesting a role-promote or compile-permission change as part of the work.

Hit Escalate on the Build row. The Build moves to the Admin queue with an "escalated" flag and your written reason. The Admin can sign off, kick it back to you, or reject outright.