releaselisted

# Cutting an iroha release iroha publishes to npm as **`@irohalabs/iroha`**. Publishing is **human-gated**: the `release.yml` workflow is `workflow_dispatch`-only and defaults to a dry run, and it authenticates with **OIDC trusted publishing** — there is no `NPM_TOKEN` and there must never be one. This skill does the local preparation and verification; the actual publish is a human dispatching the workflow. ## Preconditions - On `main`, clean working tree, CI green. - The npm trusted publisher is configured once for GitHub org `iroha924` / repo `iroha` / workflow `release.yml` (already set up; nothing to do per-release). ## 1. Bump the version Update **all four** to the same semver value — `manifests.test.ts` asserts they match, so a missed one fails CI: - `PLUGIN_VERSION` in `packages/plugin/src/metadata.ts` - `version` in `packages/plugin/package.json` - `CLI_VERSION` in `packages/cli/src/index.ts` (the `iroha --version` string) - `SERVER_VERSION` in `packages/mcp/src/server.ts` (the MCP handshake version) ## 2. Write the changelog entry Add a `## X.Y.Z` section at the top of `CHANGELOG.md` describing what a user gets. `compatibility.md` §13 requires the version to match the changelog, and `release.yml` **fails the release** if the entry is missing — so this is a gate, not a courtesy. Write what changed for someone installing the package, not what the PRs were titled; the GitHub Release already carries the PR list via `--generate-notes`. A defect fix is worth a s