docs: say what the release setup actually is

.github/workflows/release.yml

@@ -6,10 +6,9 @@
 # than in any file here, and no checkout can prove they are still true. Below
 # is the list, what breaks if one of them is undone, and where each stands.
 #
-# None of it is in place yet. Nothing has been published under this name and
-# main carries no ruleset, so every STATUS reads "to do". Work through them
-# before the first dispatch, and update the STATUS lines as you go. They are
-# the only record.
+# All of it is in place and has been since the first releases. Keep the STATUS
+# lines current as any of it changes. They are the only record, and a stale
+# one is worse than none.
 #
 #   1. A trusted publisher on npmjs.com for @kensio/rainlytics, pointing at
 #      this repository, this workflow file, and the "release" environment
@@ -23,37 +22,44 @@
 #      @kensio/rainlytics, attach the publisher, and let everything after it
 #      go through OIDC. That first version carries no provenance attestation,
 #      and it will be the only version without one.
-#      STATUS: to do. npm exposes no public endpoint for this. A checkout can
-#      never verify it, and that is the reason for writing it down here.
+#      STATUS: done. Every version from 0.1.1 onward carries a provenance
+#      attestation, which is what a publish through OIDC leaves behind, and
+#      0.1.0 is the hand-pushed one that created the package. npm exposes no
+#      public endpoint for the publisher itself. A checkout can never verify
+#      it, and that is the reason for writing it down here.
 #
 #   2. A repository environment named "release". Adding a required reviewer
 #      makes a publish wait for a second pair of eyes. Worth having if anyone
 #      else ever gains write access. Starting the run is already a deliberate
 #      act, and approving your own run adds little on its own.
-#      STATUS: to do. Create it, and put a branch policy on it.
+#      STATUS: done, with a branch policy and no required reviewer. A reviewer
+#      is where that decision would be reversed.
 #
 #   3. Settings -> Actions -> General -> "Allow GitHub Actions to create and
 #      approve pull requests", for the version job at the bottom. Without it
 #      `gh pr create` fails with a permissions error that never mentions the
 #      setting.
-#      STATUS: to do.
+#      STATUS: done. The version job has opened its pull request on every
+#      release from 0.1.3 onward.
 #
 #   4. Squash as the only merge method, with "Default commit message" set to
 #      "Pull request title". Everything below assumes a commit on main is a
 #      pull request title, because that is what semantic-release reads and
 #      what the release notes are made of. A merge commit or a rebase merge
 #      puts subjects on main that pr.yml never checked, and re-enabling either
 #      one quietly removes the guarantee the Title check exists to give.
-#      STATUS: to do.
+#      STATUS: done. Squash is the only method the repository allows, and the
+#      subject it takes is the pull request title.
 #
 #   5. A ruleset on main requiring the checks pr.yml posts: Lint, Build, and
 #      both halves of the test matrix, "Test (Node 22.x)" and
 #      "Test (Node 26.x)". Several comments below explain themselves in terms
 #      of it, in particular why the version job opens a pull request rather
 #      than pushing. Add pull requests, and refuse deletion and
 #      non-fast-forward pushes, while you are in there.
-#      STATUS: to do. Adding a runtime to that matrix in pr.yml adds a check
-#      name here, and the ruleset will not notice on its own.
+#      STATUS: done. The ruleset names those four checks and refuses deletion
+#      and non-fast-forward pushes. Adding a runtime to that matrix in pr.yml
+#      adds a check name here, and the ruleset will not notice on its own.
 
 name: Release
 
@@ -67,12 +73,12 @@ on:
   # Running this from a branch other than main is harmless — .releaserc.yaml
   # releases from main only, so semantic-release finds nothing to do.
   #
-  # Worth knowing before the first run. semantic-release starts at 1.0.0 when
-  # it finds no tag, whatever the commit subjects say and whatever version
-  # package.json holds (0.0.0, until the first release writes a real one
-  # back). A version pushed to npm by hand to bootstrap item 1 above is not a
-  # tag and does not count. Anchoring a 0.x line takes an annotated tag: push
-  # v0.1.0 and the next run works out 0.1.1 from there.
+  # The tags decide the version and nothing else does. semantic-release starts
+  # at 1.0.0 when it finds no tag, whatever the commit subjects say and
+  # whatever version package.json holds, and a version pushed to npm by hand
+  # is not a tag. That is why the 0.x line here was anchored by tagging v0.1.0
+  # before the first run, and why a stale `version` in package.json costs
+  # nothing.
   workflow_dispatch:
     inputs:
       minor:
@@ -113,8 +119,7 @@ permissions: {}
 # pr.yml uses. Those are the names intended as main's required checks, and a
 # ruleset matches a check by name whatever workflow posted it, so a release
 # dispatched from a branch with an open pull request would otherwise report
-# into that pull request's gate. That holds whether or not the ruleset of item
-# 5 exists yet, and the distinct names are worth keeping either way.
+# into that pull request's gate, which is the ruleset of item 5 above.
 #
 # Spelled out rather than calling `pnpm check`, which starts with `pnpm fmt`
 # and rewrites files instead of reporting on them. Keep these jobs and the ones