# Publish and review

> Send a version for review from your terminal. People review every version, and installs are pinned to the code they reviewed.

## Before you publish

```sh
mixel check --strict
mixel test
```

`--strict` fails on warnings too, so nothing is left for a reviewer to send back: every permission has a real reason, and nothing is declared that the code doesn't use. Then make sure `app.json` is ready for Mixel's Apps section:

- `summary` is one sentence about what the app does for a musician, not the one `mixel new` wrote.
- `version` is higher than the last one you published (`0.1.0`, then `0.1.1` or `0.2.0`).
- `icon` and `accent` give it a face in the Apps section. `icon` is a square `.svg` or `.png` in the app.
- A page, if you have one, is built: `dist/` is committed and up to date.

If the app lists Python packages, lock them, so Mixel installs exactly the versions that were reviewed:

```sh
uv lock
```

Commit `uv.lock` with the rest. The registry refuses an app with packages and no lock (`lock_missing`).

## The repository

Reviewers read your code on GitHub. Give the app its own public repository, with `app.json` at the top, and push your work:

```sh
git init
git add -A
git commit -m "Make It Mono 0.1.0"
git remote add origin https://github.com/you/make-it-mono.git
git push -u origin main
```

Keep `.venv/` and `node_modules/` out of git; `mixel new` writes a `.gitignore` that does.

## Sign in

```sh
mixel login
```

It shows a short code and opens your browser; confirm the code there with your Mixel account. The sign-in stays on this computer, readable only by you.

## Send it for review

```sh
mixel publish --dry-run
mixel publish
```

`publish` runs `mixel check --strict`, checks that the commit is pushed, then sends the repository and that exact commit. `--dry-run` does everything except the sending, so you can see what would go.

```sh
mixel status
```

It shows where each version is, and any notes a reviewer left. Fix what they ask, raise `version`, push, and publish again.

## What review looks at

People review every version before it reaches the Apps section. They look at:

- **What it asks for.** Every permission is used, and its reason is honest and specific.
- **What it does.** The code keeps to what `app.json` declares: no programs run, no sockets, no telemetry, no files outside what the person chose, the app's own data and its temporary folder.
- **How it reads.** It says what it does for a musician, in plain words, and works in light and dark.
- **That it's whole.** The page matches the source in the repository, and the app installs on a clean computer with only the packages it locks.

Before a person looks, the registry checks that `app.json` is valid, that the commit is on GitHub, and that the packages are locked.

## Updates

When a version is accepted, everyone who installs the app gets that exact commit. Later pushes change nothing until you publish a new version and it's reviewed too. Raise `version` each time, and never change `name`: it's how Mixel knows it's the same app.

`sdk` in `app.json` says which versions of Mixel the app runs on, as a caret range like `^0.3`. When someone's Mixel is outside that range, it doesn't open the app and asks them to update Mixel instead.