@catladder/cli 5.1.1 → 5.1.3

package/dist/skills/catladder-migrate-ci-backend/SKILL.md

@@ -183,10 +183,15 @@ skill for the exact command surface.
 - **GitLab** needs a `GL_TOKEN` project access token (named
   `semantic-release`) to push the release commit and tag. It is created
   and rotated by `yarn catladder project setup`.
-- **GitHub** needs nothing extra — the release jobs use the built-in
-  `github.token`. Tags pushed by that token do not retrigger workflows,
-  so the release job dispatches the tagged-release workflow explicitly;
-  that is built in and needs no configuration.
+- **GitHub** needs the release deploy key that `yarn catladder project
+  setup` provisions together with the merge gating (Step 9): the release
+  job pushes the release commit and tag over ssh with it, because the
+  built-in `github.token` can never bypass the required `catladder ✅`
+  check on the default branch (the push fails with GH013 otherwise).
+  Without merge gating the job falls back to the token. The release
+  commit carries `[skip ci]` and the release job dispatches the
+  tagged-release workflow explicitly (one run per tag); that is built
+  in and needs no configuration.
 - **Only one backend should own releases at a time.** Both backends
   generate release jobs, and with `releases: { when: "auto" }` both would
   try to tag the same commit. During the parallel phase, agree with the
@@ -287,9 +292,13 @@ now-wrong `gitRemote`, regenerate once more, and finish with
   token bypass rulesets, so setup provisions a write deploy key
   ("catladder release", private half in the `CATLADDER_RELEASE_KEY`
   actions secret; deploy keys never expire) that the release job
-  pushes with over ssh. Classic branch protection has no bypass list
+  pushes with over ssh — with both release methods, semantic-release
+  and changesets. Classic branch protection has no bypass list
   at all, which is why setup uses a ruleset and migrates old
-  classic-protection gating away. `project doctor` verifies all of it.
+  classic-protection gating away. `project doctor` verifies all of it,
+  including that the committed release workflow runs the release image
+  of the installed catladder (an older semantic-release image pushed
+  with the token and ignored the key — regenerate with `catenv`).
   Required reviews stay a human choice.
 - Tell the team where the pipeline lives now and how manual actions
   work there (on GitHub, manual jobs are dispatch workflows in the

package/dist/skills/catladder-pipelines/SKILL.md

@@ -70,8 +70,9 @@ jobs). Their definitions are materialized into
 `.catladder-generated/images/` and built in the project's own registry
 under `catladder/` (content-hashed, rebuilt only on change).
 `.catladder-generated/catci/` holds a small bundled CI companion used by
-generated jobs (e.g. the release security audit) — all generated, never
-edit.
+generated jobs (e.g. the release security audit) plus a `package.json`
+pinning the folder to CommonJS (needed when the project's root
+`package.json` has `"type": "module"`) — all generated, never edit.
 
 Projects can declare their own job images under `images` in
 `catladder.ts` (`🐳 image <name>` build jobs, pushed to `job-images/` in

package/dist/skills/catladder-releases/SKILL.md

@@ -128,6 +128,20 @@ the `security` commands in the `catladder-cli` reference.
   MR adding a changeset describing the accumulated work.
 - Wrong version bump → check commit types (semantic-release) or the bump
   levels in the changeset files (changesets).
+- GitHub: the push is rejected with `GH013 … Required status check
+  "catladder ✅" is expected` (or GH006) → the release push has to use
+  the release deploy key, the only actor that bypasses the merge-gating
+  ruleset. `yarn catladder project setup` provisions it (deploy key
+  `catladder release` + secret `CATLADDER_RELEASE_KEY`), `yarn catladder
+  project doctor` verifies it — including that the committed release
+  workflow runs the current release image; an older semantic-release
+  image pushed with the workflow token and ignored the key (regenerate
+  with `yarn catenv` and commit).
+- GitHub, semantic-release with a project-provided `.releaserc`: keep
+  `[skip ci]` in the `@semantic-release/git` commit message. The
+  deploy-key push triggers workflows, and without the marker the release
+  commit starts a main run and the tag a second tagged run next to the
+  one the release job dispatches.
 - Tag pushed but nothing on the releases page → with `changesets` the
   entry is created via the host api after the push and never fails the
   job (the release itself is done); look for the `could not create the