CLI · Releases and history

Promotion is git-SHA-based: an environment is “at” a commit, release plan diffs against it, and release apply promotes and stamps the manifest. Everything is recorded, so history and audit are queries, not archaeology.

kiri release

kiri release plan

Diff HEAD (or --from) against the commit an environment currently runs.

Usage: kiri release plan --to <env> [OPTIONS]

Flag	Description	Default
`--to`	Target environment (`dev`\|`test`\|`prod`\|…) — required
`--from`	New state to diff against the env’s manifest `release_sha`. Any git ref: short SHA, tag, branch.	`HEAD`
`--domain`	Restrict the plan to one information domain — paths under `contracts/<domain>/` are kept; `kiri.yml` / `sources/` / `models/` entries are dropped since they aren’t domain-scoped.
`--allow-dirty`	Suppress the uncommitted-changes warning (dev-only)	off

kiri release apply

Promote a git SHA to an environment and stamp the release manifest.

Usage: kiri release apply --to <env> [OPTIONS]

Flag	Description	Default
`--to`	Target environment — required
`--sha`	SHA to promote; must resolve to the same commit as HEAD — this command does not checkout, the caller (CI or a human) is responsible for the right ref being checked out.	`HEAD`
`--tag`	Optional annotated tag stamped into the manifest — this is where the semver lives (e.g. `v1.2.0`)
`--domain`	Promote only contracts in one domain (same scoping semantics as `kiri apply --domain`); `release_sha` still stamps the project manifest as a whole
`--allow-dirty`	Promote despite uncommitted changes (dev-only escape hatch)	off
`--skip-dbt` / `--skip-fetch`	Same semantics as on `kiri apply`	off

Status and history

kiri release status — which commit SHA is live in every environment.
kiri release matrix [--output table|json] — which contract version is live in which environment, as a matrix.
kiri release contract URN — every environment’s currently-active version of one contract (e.g. orders.silver).
kiri release history [--env <e>] [--limit 20] [--output table|json] — most recent promotions, newest first.
kiri release init — populate the release-state store with the current state (first-run bootstrap). The store location comes from --database-url or DATABASE_URL.

kiri release plan --to prod
kiri release apply --to prod --tag v1.4.0
kiri release history --env prod --limit 10

kiri approve

Operator surface for gated actions: multi-approver votes and use-once bearer tokens that bind an approval to exactly one action.

Vote lifecycle

kiri approve list --workspace <urn> — pending approval requests.
kiri approve show REQUEST_ID — one request with its vote tally.
kiri approve grant REQUEST_ID --as <principal> [--rationale <text>] — record an APPROVE vote.
kiri approve reject REQUEST_ID --as <principal> [--rationale <text>] — record a REJECT vote; one veto blocks the request.
kiri approve open — open a request manually (rare; normally requests are opened by the gated surface itself). Requires --workspace, --caller, --sql-preview, --rationale, --trace-id; --required-approvers snapshots the bar (default 1).

All approve verbs share --store memory|jsonl|<database> and --store-path for the approval-store backend (file path for jsonl, connection URL for the database backend).

Token issue and consume

kiri approve issue REQUEST_ID — once a request has enough votes, mint a use-once bearer token.
kiri approve consume --token <t> (--sql-hash sha256:<hex> | --sql <raw>) — validate and consume the token against the exact SQL it was approved for. The CLI canonicalises --sql before hashing; production callers pass --sql-hash directly. A token consumed once is dead.
kiri approve consume-reconcile --token <t> --report <locked-report.json> [--environment <e>] [--snapshot-id <id>] — consume a token bound to a LOCKED reconcile report (see the migration page): the cutover approval is cryptographically tied to the exact parity evidence it was granted on.
kiri approve reconcile-hash --report <locked-report.json> — print the binding hash for a reconcile report, so approvers can verify what they are signing off.

The number of approvers a given action requires comes from policy: kiri governance approval-count --action <name> (governance page).

kiri history

Delta commit history for a bronze table — the storage-level audit of what changed and when.

kiri history --source crm --table customers --limit 10

kiri upgrade

The upgrade lifecycle for the installation itself (check → snapshot → upgrade → rollback) is documented on the build page under kiri upgrade.