# What is skmtc-hub



Several CLI commands assume a service called **skmtc-hub** without
introducing it. This page is that introduction: the nouns the hub adds
on top of a local SKMTC workspace, and which command touches which.

None of it is required for local generation. `init`, `install`,
`generate`, `clone` — the whole local loop — work with no account and
no network beyond fetching schemas and packages.

## The nouns [#the-nouns]

### Account [#account]

The owner of everything else — a **user or an org**. Hub names are
scoped the way JSR package names are: `@account/slug`, where the
account may be an org you belong to. Your PAT authenticates *you*; the
hub then authorizes you per account (org membership included).

### Stack [#stack]

A **published, immutable version of a SKMTC project** — the project's
generator set, built and uploaded as a package. A stack's identity is
the project root `deno.json#name` (`@account/slug`); versions are
semver, and re-publishing an existing version is rejected. Produced by
[`publish`](/docs/reference/cli/publish).

### Project (hub project) [#project-hub-project]

The **running side**: a hub project binds a stack version to a
registered API schema and owns execution — deployments, runs, and the
`production` alias, driven from the web app. Its editable config is
the same `client.json` shape the CLI uses locally:
[`push`](/docs/reference/cli/push) uploads yours,
[`pull`](/docs/reference/cli/pull) fetches the project's. The link
between a local workspace and its hub project is the `project` field
in `client.json` (`"@account/slug"` — the git-remote analog).

### Personal access token (PAT) [#personal-access-token-pat]

The hub's only programmatic credential, minted in the hub UI under
`Settings → Access tokens`. [`login`](/docs/reference/cli/login)
validates it and stores it in `~/.skmtc/auth.json`; `publish`, `push`,
and `pull` use it from there (or take `--token` / `$SKMTC_HUB_TOKEN`
directly).

## Which command touches what [#which-command-touches-what]

| Command                                  | Hub noun       | Direction                                          |
| ---------------------------------------- | -------------- | -------------------------------------------------- |
| [`login`](/docs/reference/cli/login)     | PAT            | store credential locally                           |
| [`publish`](/docs/reference/cli/publish) | stack          | local project → new immutable version              |
| [`push`](/docs/reference/cli/push)       | project config | local `client.json` → hub project                  |
| [`pull`](/docs/reference/cli/pull)       | project config | hub project → local `client.json`                  |
| [`project`](/docs/reference/cli/project) | project        | create / remove a hub project from the local setup |

## The division of labor [#the-division-of-labor]

The CLI ships bytes; the hub runs them. `publish` never deploys —
it uploads a version. Hub projects pin a version, and deployments,
runs, and promotion to `production` happen in the web app. That split
keeps the CLI's surface small (no deploy flags, no run orchestration)
and keeps everything executable addressable by an immutable stack
version.

## See also [#see-also]

* [`publish`](/docs/reference/cli/publish) — stack identity, versioning, and the 409 rule
* [`push`](/docs/reference/cli/push) / [`pull`](/docs/reference/cli/pull) — config
  ownership in both directions
* [`login`](/docs/reference/cli/login) — PAT storage and `--origin`