Skip to main content

kapi status

Show where the project stands: per-scope coverage against the ship gates and, on a connected project, the server delta and the venue kapi up would run on. The same coverage and ship states appear on the project dashboard in the browser. kapi status always exits 0, because a locale that is behind is pending work.

Usage​

kapi status [flags]

What it shows​

The coverage grid​

One row per scope, a locale or a locale/collection pair, with the number of blocks, one column per rung of the target ladder (the share of blocks that have reached drafting, translation, review), a pipeline bar showing distance to the bar, and a ship column. The ship column shows a verdict:

  • approved (a person approved the content) or translated (translated with its checks green) when the scope clears its gate;
  • blocked: <rung>, naming the first unmet gate, so it points at the work;
  • not gated when no gate matches the scope.

Under the grid, two lines report how many translations carry a decision made against content that has since changed, and how many nobody has judged yet. A project that names no target language reports itself as monolingual.

The server section​

On a connected project (the recipe declares a bowrain: block), the plugin adds the server's standing: the server URL and project, blocks pending push and pending pull against the tree the project last declared (see kapi push), the last sync time, any run in flight, and two more lines:

  • terms: when the workspace's governed terms were last snapshotted into the local terms store (concept and relation counts), or never synced when no concept pull has run; refresh with kapi pull --concepts.
  • governance: how this project's declared points, channels and voice compare with the workspace's, so you see a divergence before a push reports it.

The venue​

Where kapi up would run the loop, server or local, with the recipe's bowrain.converge policy, and a note when the venue is degraded (a server is declared but the bowrain plugin is missing).

Options​

FlagDescription
--localeLimit the grid to a single target locale
--source-langSource language (overrides the project's source_language)
--reviewList the blocks awaiting review in every language, the source language among them, instead of the grid; approve a translated one with kapi apply
--lang <tag>With --review, list only these languages (repeatable, or comma-separated)
--shipEmit the minimal ship.json manifest (locale → shippable, state, and any dimension that governs nothing there) instead of the grid: the shape a language picker consumes to hide locales that are not shippable and badge those shipped on machine review
--emit <path>With --ship, write the manifest to this path instead of stdout
--jsonOutput the structured result as JSON

kapi status --ship --emit ship.json at build time writes the same manifest the server publishes at GET /api/v1/projects/:id/ship.json, so a site built from a checkout and a site reading the server agree. See Ship states.

Examples​

# The coverage grid, the server delta and the venue
kapi status

# One locale
kapi status --locale fr

# The review worklist, and one language of it
kapi status --review
kapi status --review --lang fr

# The ship manifest for a language picker, written at build time
kapi status --ship --emit public/ship.json

# Machine-readable
kapi status --json

Exit codes​

  • 0: status displayed (behind is pending work, not an error)
  • 1: error (project not found, and so on)

When to use​

Run kapi status to:

  • Check before push to see what will be uploaded
  • Check after pull to see what changed
  • See what is shippable before a release, and what blocks the rest
  • Troubleshoot sync issues or unexpected state