feat(kit): publishing necessary stuff for kit

Author: cdskill

.agents/skills/qalma-release/SKILL.md

@@ -5,45 +5,54 @@ description: Guide npm releases and the publish pipeline for @qalma/editor and @
 
 # Qalma Release
 
-`@qalma/editor` and `@qalma/skills` are published to npm under the `latest`
-dist-tag while the public API stabilizes. The packages are pre-1.0 and now use
-beta prereleases for public early-adopter cuts. There is no stable version to
-reserve `latest` for yet, so `latest` tracks the newest beta and remains what
-npmjs features and what plain installs resolve.
-
-Releases are tag-driven: a `vX.Y.Z[-prerelease]` git tag pushed to `main`
-triggers GitHub Actions, which builds, re-derives the version from the tag, and
-publishes both packages via npm's OIDC Trusted Publisher (no npm token in CI).
-When a stable `1.0.0` is cut, publish it as `latest` and move later
-prereleases back to a separate `next`/`beta` dist-tag.
+`@qalma/editor`, `@qalma/skills`, and `@qalma/kit` are published to npm under
+the `latest` dist-tag while the public API stabilizes. The packages are
+pre-1.0, but public releases use normal semver versions without prerelease
+suffixes. The scripted release path bumps the minor version on every release
+(`0.2.0`, `0.3.0`, and so on).
+
+Releases are tag-driven: a `vX.Y.Z` git tag pushed to `main` triggers GitHub
+Actions, which builds, re-derives the version from the tag, and publishes all
+three packages via npm's OIDC Trusted Publisher (no npm token in CI).
 
 For the full architecture, history, and troubleshooting, read
 [release-pipeline.md](references/release-pipeline.md).
 
 ## Cut a Release
 
 1. Make sure `main` is clean and up to date (`git status`, `git pull`).
-2. Preview the beta bump:
-   - First beta from the alpha line: `pnpm release:beta:init:dry-run`
-     (uses `preminor --preid beta`, e.g. `0.1.0-beta.0`).
-   - Subsequent betas: `pnpm release:beta:dry-run`
-     (uses `prerelease --preid beta`, e.g. `0.1.0-beta.1`).
-   - Explicit stable or one-off version:
-     `pnpm nx release <version> --skip-publish --dry-run`.
-3. Run the matching release command:
-   - First beta: `pnpm release:beta:init`.
-   - Subsequent beta: `pnpm release:beta`.
-   - Explicit stable or one-off version:
-     `pnpm nx release <version> --skip-publish`, then
-     `node tools/sync-changelog-doc.mjs`.
+2. If the current version is still on the historical beta line, bootstrap the
+   first normal semver release explicitly:
+
+   ```sh
+   pnpm nx release 0.2.0 --skip-publish --dry-run
+   pnpm nx release 0.2.0 --skip-publish
+   node tools/sync-changelog-doc.mjs
+   ```
+
+   This one explicit version is needed because Nx's native `minor` bump from
+   `0.1.0-beta.4` resolves to `0.1.0`, while Qalma's new policy is to move to
+   the next minor without a suffix.
+
+3. After `0.2.0`, preview the next minor bump with `pnpm release:dry-run`.
+4. After `0.2.0`, run the normal release command with `pnpm release`.
+
+   For an explicit one-off version, call Nx directly so the version argument is
+   passed before the changelog-sync command:
+
+   ```sh
+   pnpm nx release <version> --skip-publish
+   node tools/sync-changelog-doc.mjs
+   ```
 
    These scripts or commands run `nx release ... --skip-publish`, then sync the
    generated editor changelog into the docs changelog. The release portion:
    - Runs the `preVersionCommand`
-     (`pnpm nx run-many -t build -p editor skills`).
+     (`./node_modules/.bin/nx run-many -t build -p editor skills ui-kit`).
    - Writes the new version into `libs/editor/package.json` and
-     `dist/libs/editor/package.json`, plus `libs/skills/package.json` and
-     `dist/libs/skills/package.json`.
+     `dist/libs/editor/package.json`, `libs/skills/package.json` and
+     `dist/libs/skills/package.json`, plus `libs/ui-kit/package.json` and
+     `dist/libs/ui-kit/package.json`.
    - Generates project changelogs from conventional commits.
    - Commits the manifest and changelog change as
      `chore(release): publish <version>`.
@@ -55,31 +64,32 @@ For the full architecture, history, and troubleshooting, read
    `docs(changelog): sync docs changelog from release` commit if the docs
    changelog changed. The release tag intentionally stays on the release commit.
 
-4. `git push --follow-tags` to push the commit and the tag. Pushing the tag is
+5. `git push --follow-tags` to push the commit and the tag. Pushing the tag is
    the actual deploy trigger — `.github/workflows/release.yml` runs, publishes
-   `@qalma/editor@<version>` and `@qalma/skills@<version>` under the `latest`
-   dist-tag, then creates a GitHub release whose notes are this version's
-   section of `libs/editor/CHANGELOG.md`.
-5. Watch the "Release" workflow run in GitHub Actions to confirm the publish
+   `@qalma/editor@<version>`, `@qalma/skills@<version>`, and
+   `@qalma/kit@<version>` under the `latest` dist-tag, then creates a GitHub
+   release whose notes are this version's section of `libs/editor/CHANGELOG.md`.
+6. Watch the "Release" workflow run in GitHub Actions to confirm the publish
    and the GitHub release both succeeded.
 
-Before the first coupled tag, ensure `@qalma/skills` exists on npm and has the
-same Trusted Publisher configuration as `@qalma/editor`. If npm package settings
-are not available yet, bootstrap `@qalma/skills` once manually, configure the
-Trusted Publisher, then let tags publish both packages going forward.
+Before the first coupled tag that includes all packages, ensure `@qalma/skills`
+and `@qalma/kit` both exist on npm and have the same Trusted Publisher
+configuration as `@qalma/editor`. If npm package settings are not available yet,
+bootstrap the missing package once manually, configure the Trusted Publisher,
+then let tags publish all packages going forward.
 
 ## Versioning Conventions
 
-- Use beta prereleases for public early-adopter releases before `1.0.0`
-  (`0.1.0-beta.N` unless an explicit version is intentionally chosen). `latest`
-  tracks the newest beta until a stable release exists, keeping npmjs and plain
-  installs current. At `1.0.0`, stable remains on `latest` and later
-  prereleases should move to a separate `next`/`beta` dist-tag.
-- Keep the historical alpha line as history only. Do not cut new alpha releases
-  unless the project intentionally reopens an alpha track and updates this skill
-  plus the release scripts again.
+- Use normal semver releases before `1.0.0`; do not add a `-beta`, `-alpha`, or
+  other prerelease suffix on the scripted release path.
+- The default release script always bumps to the next minor. From the historical
+  beta line, use one explicit `0.2.0` release first; after that the normal
+  script moves `0.2.0` to `0.3.0`, then `0.3.0` to `0.4.0`, and so on.
+- Keep the historical alpha and beta lines as history only. Do not cut new
+  prereleases unless the project intentionally reopens a prerelease track and
+  updates this skill plus the release scripts again.
 - Never push a `v*` tag for a version already published to npm — the workflow
-  checks both package versions before publishing, and re-publishing an existing
+  checks all package versions before publishing, and re-publishing an existing
   version fails before any package is published.
 - `BREAKING CHANGE:` commit footers still document API breaks for history, even
   though the package remains pre-1.0.
@@ -89,6 +99,6 @@ Trusted Publisher, then let tags publish both packages going forward.
 - Run plain `nx release` (without `--skip-publish`) locally — it will attempt
   `npm publish` from your machine and re-introduce the 2FA/token friction the
   Trusted Publisher setup removed.
-- Hand-edit package `version` fields — use the beta release scripts or
+- Hand-edit package `version` fields — use `pnpm release` or
   `pnpm nx release <version> --skip-publish` so the commit, tag, and `dist`
   manifests stay in sync.