For Developers

A session is a live working copy of a project, pulled from a specific version. You join one of three ways: click a link a teammate shared, double-click an active session in the project view, or start a new session yourself from New Session.

On join, the encrypted working copy streams into your in-RAM cache. Nothing lands on disk. You'll see other participants' cursors and selections immediately — Loro CRDTs merge every edit in real time, so there are no conflicts to resolve and no save button to press.

Up to a thousand people can be in a single session. In practice most sessions are 2–5. Leave at any time by closing the tab; your in-flight edits are already on the server.

Velocity tracks who wrote every line. Human-authored code renders in the normal monochrome theme. AI-authored code — anything that came in through the CLI tab from Claude Code, Codex, or Gemini — renders with a hot-pink highlight under the text. The highlight is permanent, audit-grade metadata, not a transient styling layer.

Edit an AI-authored line by hand and the highlight clears on that line. Accept a CLI suggestion wholesale and the highlight persists. Reviewers and Admins see the same paint when they read your diff, so AI involvement is never hidden.

The Code tab top bar has a Diff Toggle — a small switch that swaps the editor between two views without leaving your spot in the file.

• Live view. The default. The current working copy as everyone is editing it right now.
• Diff view. The same file overlaid with the diff against the version you pulled from. Additions and removals appear inline; AI authorship paint shows through.

Use it to sanity-check your own work before submitting, or to read what a teammate just changed without leaving the session. Toggle state is per-tab — you can have one file in diff and another live.

When the session is ready to ship, open the Build tab and click Submit for Review. The submission bundles the diff against the version you pulled from, your notes (markdown supported), the session ID, and a list of Reviewers eligible to approve.

1. Write a clear note. What changed, what didn't, what to look at first.
2. Pick one or more Reviewers from the project's Reviewer pool. Any one of them can approve.
3. Optionally run the compliance scanners (Semgrep / Trivy / Gitleaks / License Finder) pre-submit.
4. Click submit. The session stays open — you can keep working on the next thing.

Approved submissions move to an Admin for the final merge. Rejected submissions come back with inline comments and a status of Needs changes. The full state is visible from the Build tab on every session that produced it.

When a Reviewer leaves comments, you get an OS-level toast and a bell-icon notification. Open the submission from the Build tab — comments are anchored to lines, threaded, and resolve when you push a fix.

To address a comment, jump back into the session (or start a new one from the same submission), make the edit, and re-submit. The Reviewer sees the new diff stacked under the original; they don't re-read the whole change, just the delta.

If you disagree with a comment, reply inline. Reviewers can resolve their own comments or escalate to an Admin. Nothing merges without explicit Reviewer approval plus Admin sign-off.

The top bar of every session has a fixed set of tabs. The four you'll spend most of your time in:

• Code. The editor — Code OSS embedded, with Velocity-specific extensions for cursors, AI authorship paint, the Diff Toggle, inline comments, and snippet insertion.
• CLI. Pick Claude Code, Codex, or Gemini. Pick a model. Pick org-provided keys or your own. Pick which MCPs are active. Every prompt and response is logged to the audit feed forever — assume your CLI history is reviewable.
• Files. Project tree, with search, rename, move, and per-file history. Right-click a file to see the full edit timeline across sessions.
• Search. Project-wide content search with regex and filters by author, by AI vs human, by date. Faster than grep because it's served from the indexed cloud working copy.