@catladder/cli 5.0.0 → 5.1.0

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

@@ -52,6 +52,11 @@ workflows the same way (`▶️ catladder deploy`, `⏹️ catladder stop`,
 
 ## `method` — how the version is decided
 
+Whichever method runs, the release ends the same way: a `vX.Y.Z` tag, a
+`CHANGELOG.md` entry, a `chore(release): <version>` commit, and an
+entry on the releases page of the git host (gitlab `/-/releases`,
+github `/releases`) carrying the release notes.
+
 ### `semantic-release` (default)
 The version is derived automatically from **conventional commit
 messages** since the last release (`fix:` → patch, `feat:` → minor,
@@ -63,8 +68,10 @@ Developers declare changes intentionally as **`.changeset/*.md` files**
 (the official changesets format: a bump type + a human-written summary).
 The release job consumes all pending changesets, takes the highest bump,
 computes the next version from the last `v*` git tag, writes the
-changelog, commits `chore(release): <version>`, and pushes the tag. An
-empty `.changeset/` folder means there is nothing to release.
+changelog, commits `chore(release): <version>`, pushes the tag and
+creates the release entry on the git host (gitlab `/-/releases`,
+github `/releases`) with the changelog as its description. An empty
+`.changeset/` folder means there is nothing to release.
 
 Add a changeset by creating `.changeset/<name>.md`:
 
@@ -121,6 +128,13 @@ 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).
+- 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
+  release entry` warning at the end of the release job log. On gitlab
+  it needs `GL_TOKEN` (`catladder project renew-token`). Releases
+  tagged before catladder created entries have none — that is not fixed
+  retroactively, create them by hand from the tag.
 - Inspect the job with `yarn catladder project ci job-log` (see the
   `catladder-cli` skill).
 

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

@@ -80,6 +80,22 @@ All of these write to the secrets vault (the source of truth) and
 automatically mirror to the enabled CI backends — which vault is
 configured makes no difference to the commands.
 
+## Provisioned secrets
+
+A few secrets are not typed in by a human but created by
+`yarn catladder project setup`: the gcloud deploy service account key
+(`GCLOUD_DEPLOY_credentialsKey`) and the kubernetes deploy credentials
+(`KUBE_TOKEN`, `KUBE_CA_PEM`, `KUBE_URL`). They travel the same route as
+every other secret — vault first, then the enabled CI backends — but
+they are *hidden*: they never show up in `secrets-list`, in the editor
+or in a pulled document, and they must never be set by hand.
+
+Re-running `project setup` **rotates** them (a fresh credential is
+created and the old one revoked). That is also the answer whenever they
+are missing somewhere — after switching `secrets.vault`, for instance:
+a `secrets-pull`/`secrets-push` round trip does not carry hidden keys
+over, so re-run `project setup` to provision them into the new vault.
+
 ## GitHub pipelines
 
 GitHub Actions cannot read the vault at runtime; secrets are mirrored