# Projects and status

Three commands that answer questions about a project rather than changing it: which projects can this key reach, what is published, and is this change safe to merge.

## projects list

Lists the projects your API key can reach: project id, name, published ontology version, and SQL dialect. Use it to look up a project id without opening the web app.

```bash
cassis projects list

# Machine-readable
cassis projects list --json
```

The id is what `--project` and `CASSIS_PROJECT_ID` take. In a pulled checkout it is already in `cassis/project.yml`, so you rarely need this twice.

## status

Shows the project’s published version (number, label, git commit), whether unpublished changes await publication, the git-sync binding, how many Data source review items are pending, and how your local git HEAD relates to the published commit: in sync, N commits ahead, or diverged.

```bash
# Quick glance
cassis status --project ...

# Wait for a GitHub App sync to record local HEAD
cassis status --project ... --watch
```

- **Pending source changes** `Source changes pending review: N` appears when the [Data source review queue](/curate/data-source-changes/) is not empty, with the breaking count alongside when any change breaks something in the ontology. Read the queue itself with [`cassis source-changes list`](/reference/cli/source-changes/). Needs cassis-cli 1.6.0 or newer; before that the line is simply absent.

- **Watch mode** `--watch` polls until the published commit matches your local HEAD, then exits 0. `--poll-interval` (5 seconds) and `--timeout` (10 minutes) control the cadence. It prints one line per poll only when the state changed, so a long wait stays quiet.

- **GitHub App sync only** The GitHub App records a commit on the published version, so watch mode can confirm “the published commit is my commit.” A provider-agnostic `ontology upload` does not record a git SHA; use the upload job’s exit status and plain `cassis status` instead.

## verify

Runs the full local gate in one verb: `ontology fmt --check`, then `ontology check`, then `eval run`, stopping at the first failure.

```bash
# Full pre-merge gate
cassis verify --project ...

# Skip the eval suite
cassis verify --no-eval --project ...
```

It is a convenience wrapper, not a new primitive: each step runs exactly as if you had called it directly, with the same output and the same meaning. One command in a checkout answers “is this change safe to merge?”, and one job in CI does the same. See [Set up CI](/build/ci/).