ci: simplify ktx release flow

docs/release.md

@@ -15,7 +15,9 @@ KTX has two npm release channels:
 Run rc releases from the source branch you want to publish. The workflow
 creates or updates the `next` prerelease branch from that source branch before
 running semantic-release, because semantic-release requires a dedicated
-prerelease branch in addition to the stable `main` branch.
+prerelease branch in addition to the stable `main` branch. You can publish an
+rc from `main` when you want to validate the current stable branch before a
+stable release.
 
 Run stable releases only from `main`. The workflow rejects stable releases from
 other branches.
@@ -31,16 +33,24 @@ Before you publish, confirm these requirements:
   GitHub Actions run through OpenID Connect.
 - The repository has release metadata in `release-policy.json` for the current
   public package line, such as `0.1.0-rc.1` or `0.1.0`.
+- The repository has a stable baseline tag when you need semantic-release to
+  publish the first stable version as `0.1.0`.
 
-If no stable baseline tag exists, semantic-release treats the stable run as the
-first release. KTX seeds that first stable release from the base version in
-`release-policy.json`, so `0.1.0-rc.6` promotes to `0.1.0` instead of
-semantic-release's default `1.0.0`.
+semantic-release doesn't support choosing an arbitrary first `0.x` stable
+release. If KTX has no stable tag yet and you need the first stable release to
+be `0.1.0`, create and push the baseline tag once before running the live
+stable workflow:
 
-KTX blocks automatic major releases. A major version requires an intentional
-manual release path that updates release metadata and creates the intended
-version explicitly; don't rely on semantic-release commit analysis for major
-bumps.
+```bash
+root_commit="$(git rev-list --max-parents=0 HEAD | tail -n 1)"
+git tag v0.0.0 "${root_commit}"
+git push origin v0.0.0
+```
+
+KTX follows the same versioning schema as the main Kaelio release workflow:
+breaking-change and `major` commit markers create a minor release, not an
+automatic major release. A major version requires an intentional manual release
+path.
 
 ## Dry-run a release
 
@@ -51,7 +61,7 @@ publishing to npm.
 2. Select **KTX Release**.
 3. Select the branch to release from.
 4. Set **release_kind** to `rc` or `stable`.
-5. Leave **publish_live** set to `false`.
+5. Set **publish_live** to `false`.
 6. Optional: Set **force_release** to `true` when you need a patch release even
    if semantic-release doesn't find a releasable commit.
 7. Run the workflow.
@@ -67,9 +77,9 @@ promoting to `latest`.
 
 1. Open **Actions** in GitHub.
 2. Select **KTX Release**.
-3. Select the source branch to release from.
+3. Select the source branch to release from, including `main` when needed.
 4. Set **release_kind** to `rc`.
-5. Set **publish_live** to `true`.
+5. Leave **publish_live** set to `true`.
 6. Optional: Set **force_release** to `true`.
 7. Run the workflow.
 
@@ -85,8 +95,8 @@ Publish a stable release from `main` after you have validated an rc package.
 1. Open **Actions** in GitHub.
 2. Select **KTX Release**.
 3. Select `main`.
-4. Set **release_kind** to `stable`.
-5. Set **publish_live** to `true`.
+4. Leave **release_kind** set to `stable`.
+5. Leave **publish_live** set to `true`.
 6. Optional: Set **force_release** to `true`.
 7. Run the workflow.
 
@@ -97,7 +107,8 @@ release metadata.
 ## Release metadata
 
 semantic-release calls `scripts/update-public-release-version.mjs` during the
-prepare step. That script updates:
+prepare step before `@semantic-release/npm` publishes the package. That script
+updates:
 
 - `package.json` with the semantic-release version.
 - `release-policy.json` with `publicNpmPackageVersion`, npm publish settings,
@@ -105,7 +116,9 @@ prepare step. That script updates:
 
 The artifact packaging and readiness scripts read `publicNpmPackageVersion`
 from `release-policy.json`, so manual version edits in build scripts aren't
-needed for rc releases.
+needed for rc releases. The semantic-release npm plugin publishes the generated
+`dist/public-npm-package` tree and writes the release tarball under
+`dist/artifacts/npm`.
 
 The bundled Python runtime wheel also derives its version from
 `publicNpmPackageVersion`. Stable npm versions are reused as-is, and rc