# Updates

This page is how a live site gets a new version of the product. It is not something you do every week from admin.

> **Caution.** An update is a pull request in **your** repo. Merging it deploys. If the release includes database files, [migrations](./backups.md) run after a backup. Let your agent run the checks. Do not skip `pnpm xylo sync`.

## What an update looks like

Core is a package. Your repo depends on a version of `@xylo/core`. A new version arrives as a pull request (from Renovate, or opened by hand).

Your agent should:

```bash
pnpm install
pnpm xylo sync
```

If sync wrote files, they commit them, then run:

```bash
pnpm xylo sync --check
pnpm typecheck
pnpm test
```

They paste the output on the pull request. You merge with a merge commit. Vercel deploys.

`pnpm xylo sync` rewrites generated files (routes, workflows, skills) from the installed core. It does not overwrite your `site/` content.

## Patch, minor, major

- **Patch** — a fix. Nothing for you to do except merge.
- **Minor** — something new, or a new setting with a default. The site keeps working. You may want to turn the new thing on.
- **Major** — your site files have to change too. The notes say `Site changes needed:`. The agent makes those on the same branch before you merge.

## Token for installs

Installing `@xylo/core` needs a GitHub token with `read:packages` in the **user-level** `~/.npmrc`, never in the repo. Vercel uses an `NPM_TOKEN` environment variable. `pnpm xylo sync --check` fails if a token line sneaks into the repo `.npmrc`.

## This docs site

The pages you are reading are exported from xylo-cms and copied into xylosoftware.dev as `cms-docs/`. Feature copy is updated in xylo-cms, then published here. Do not hand-edit `cms-docs/` except when reviewing that publish pull request.

Older docs called this page “Keeping docs current.” The owner-facing job is the version bump above.