Review and delivery
Read the change across repos in one workspace, then push it — preview first, apply against the fingerprint you reviewed.
Review it first
/ivar-reviewOpens 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
/ivar-deliverDelivery pushes to real remotes, so it is two steps with a human in between.
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.
ivar feature deliver <feature> --previewApply — 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.
ivar feature deliver <feature> --fingerprint <fp>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.
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#412Part 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.
Execution
Running an approved plan as parallel workstreams — the graph schema, how targeting is pinned, how write contracts are enforced, and the three ways reality is allowed to diverge.
Hall upkeep
Keeping the hall honest from inside the harness — reconciling against ivar.json, listing what is registered, and authoring the setup script a fresh worktree needs.