Skip to main content

kapi status

Show where the project stands: per-scope coverage against the ship gates, what is staged locally, and, on a connected project, the server delta and the venue kapi up would run on. kapi status always exits 0; a locale that is behind is pending work, not an error.

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 units, one column per rung of the target ladder (the share of units that have reached drafting, translation, review), a pipeline bar showing distance to the bar, and a ship column. Ship is a verdict rather than a percentage: it reads ready when the scope clears its gate, blocked: <rung> naming the first unmet gate so it points at the work, or not gated when no ship gate matches the scope. Units an autonomous AI approved are counted under review and qualified as such, because gates only count them under an any approver class.

Under the grid, two basis lines report what a percentage cannot: how many units carry a decision made against content that has since changed, and how many have never been judged. A project that names no target language reports itself as monolingual rather than as empty.

Staged decisions​

Decisions recorded locally but not yet written to the committed record under .kapi/state/ are counted as staged; kapi commit publishes them. A clean project prints nothing here.

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: where this project's declared points, channels and voice stand against the workspace's, so a divergence is visible before a push raises 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 units 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, verified, 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