# Review and delivery
> Read the change across repos in one workspace, then push it — preview first, apply against the fingerprint you reviewed.
Source: https://ivar.run/docs/guide/delivery

import { Callout } from 'fumadocs-ui/components/callout';
import { Step, Steps } from 'fumadocs-ui/components/steps';

## Review it first

```text
/ivar-review
```

Opens the feature in a multi-root VSCode workspace: promoted repos on the
feature branch, everyone else on their default branch. One window holding the
whole change, instead of four windows you have to correlate by hand.

## Deliver

```text
/ivar-deliver
```

Delivery pushes to real remotes, so it is two steps with a human in between.

<Steps>
  <Step>
    **Preview — side-effect-free.** Reads local state for every promoted repo:
    branch name, remote, base branch, existing PR status, HEAD and base SHAs.
    Computes a content-based fingerprint. Pushes nothing.

    ```sh
    ivar feature deliver <feature> --preview
    ```
  </Step>
  <Step>
    **Apply — pinned to what you read.** Validates the fingerprint from the
    preview you reviewed against current state, then pushes each accepted repo's
    branch and creates or updates its pull request.

    ```sh
    ivar feature deliver <feature> --fingerprint <fp>
    ```
  </Step>
</Steps>

<Callout type="warn" title="The fingerprint is never regenerated for you">
  Apply refuses if state drifted since the preview, and it never swaps in a
  freshly computed fingerprint. If someone pushed to one of the branches while
  you were reading, you find out instead of shipping something you never saw.
</Callout>

## What lands

One pull request per promoted repo, against that repo's own base, plus the links
between them — added in a second pass, because a pull request's URL only exists
once the pull request does.

```
acme/api#412   Money.currency becomes an enum
acme/web#288   regenerate billing client
               part of acme/api#412
```

## Part of, not depends on

The link records **co-belonging**, not dependency. `ivar` does not sequence your
merges and does not decide whether the client can land before the contract —
that call needs to know about deploy windows, feature flags and consumers it has
no view of.

What it removes is the archaeology. A reviewer opening `web#288` sees which
change it belongs to, instead of reconstructing it from branch names and
timestamps.