publish-nextlisted

# Publish a dev preview (`next` dist-tag) Publishes the current state of `main` as a `X.Y.Z-next.N` prerelease. Previews never move the `latest` dist-tag and do **not** get a GitHub release. ## Preconditions — check all before touching anything 1. Working tree is clean and on `main` (`git status`). Stop and ask if not. 2. npm auth is alive: `npm whoami`. A 401 here (or a 404 on `npm publish` PUT later) means expired auth — the user must run `npm login` themselves; you cannot. 3. No half-finished work the user didn't ask to ship — show `git log origin/main..HEAD --oneline` if there are unpushed commits and confirm the preview should include them. ## Steps 1. **Bump the version** in `package.json`: increment the `-next.N` suffix (e.g. `0.3.0-next.1` → `0.3.0-next.2`). If the previous release was stable, start a new series at `X.Y.Z-next.0` where `X.Y.Z` is the next planned version. Do not use `npm version` (it creates its own commit/tag). 2. **Commit and tag** — one-line commit message, matching tag: ```sh git commit -am "Release vX.Y.Z-next.N" git tag vX.Y.Z-next.N ``` 3. **Pack**: `bun pm pack` (the `prepack` script builds the client). Verify the tarball before publishing: ```sh tar -tzf moi-computer-X.Y.Z-next.N.tgz | grep -c '^package/dist/' # must be > 0 tar -tzf moi-computer-X.Y.Z-next.N.tgz | grep -Ei '\.env|secret' # must be empty ``` 4. **Publish under the `next` tag** — the flag is mandatory, otherwise the prerelease hijacks `latest`: