docs: pre-tag issue gate + TYPO3 14 hidden version surfaces

skills/github-release/references/ecosystem-detection.md

@@ -20,11 +20,28 @@ Identify which version files need updating based on the project's ecosystem. A p
 |------|--------------|---------|
 | `ext_emconf.php` | `'version' => 'X.Y.Z'` | `'version' => '13.8.1'` |
 | `composer.json` | `"version": "X.Y.Z"` | `"version": "13.8.1"` |
-| `Documentation/guides.xml` | `<guide version="X.Y.Z">` or `version` attribute | `version="13.8.1"` |
+| `composer.json` | `extra.typo3/cms.version` (separate from `"version"`) | `"extra": {"typo3/cms": {"version": "13.8.1"}}` |
+| `Documentation/guides.xml` | `version=` **and** `release=` attributes | `version="13.8.1" release="13.8.1"` |
+| `Documentation/Changelog.rst` | rendered changelog page — add a `Version X.Y.Z (date)` section | `Version 13.8.1 (2026-...)` |
+| `CHANGELOG.md` | stamp `[Unreleased]` → `[X.Y.Z] - date` **and** the footer compare links | `[13.8.1]: .../compare/v13.8.0...v13.8.1` |
 | `Documentation/**/*.rst` | `.. versionadded:: X.Y.Z` | `.. versionadded:: 13.8.0` |
 | `Documentation/**/*.rst` | `.. versionchanged:: X.Y.Z` | `.. versionchanged:: 13.8.1` |
 
-Note: RST `versionadded`/`versionchanged` directives should only be updated when they reference the **current release being prepared**, not historical entries.
+Notes:
+
+- **`composer.json` has TWO independent version surfaces.** Besides the
+  top-level `"version"`, TYPO3 14's deprecation #108345 (drop the `ext_emconf.php`
+  version in favour of composer metadata) means extensions also carry
+  `extra.typo3/cms.version` (+ `providesPackages`). It is a *different* field from
+  `"version"` and is easy to miss — a mismatch fails the extension's own
+  `VersionConsistencyTest` in CI. Bump both.
+- **`Documentation/guides.xml`** carries both `version` and `release` attributes;
+  update both. This file drifts silently (it renders docs.typo3.org) and is a
+  frequent miss.
+- **`CHANGELOG.md`** needs the footer compare-link block updated too, not just the
+  section stamp — the `[Unreleased]` link and a new `[X.Y.Z]` link.
+- **RST `versionadded`/`versionchanged` directives** should only be updated when they
+  reference the **current release being prepared**, not historical entries.
 
 ### PHP / Composer
 

skills/github-release/references/release-process.md

@@ -20,6 +20,7 @@ The hooks in this repository block `gh release create` and `gh release delete` t
 ### Phase 1: Preparation
 
 ```
+0. Triage open issues from the current work stream (see "Issue gate" below)
 1. Detect ecosystem (see ecosystem-detection.md)
 2. Determine next version number:
    - From conventional commits (feat → minor, fix → patch, BREAKING CHANGE → major)
@@ -38,6 +39,25 @@ The hooks in this repository block `gh release create` and `gh release delete` t
 7. Push branch and open PR
 ```
 
+#### Issue Gate (Step 0) — Never tag over an untriaged known issue
+
+Before
+tagging, list open issues (`gh issue list --state open`), and for each issue
+**created or touched during the current work stream**, classify it:
+
+- *regression introduced by this release* → must be fixed before tagging;
+- *pre-existing latent* → usually not a blocker, but say so explicitly to the
+  user before tagging;
+- *test-only / infra* → not a blocker.
+
+Anything of **unclear severity** — including an issue you filed yourself whose
+text hypothesises "production bug" — is decided by the user, not silently
+shipped. A user's task order that includes "release" does **not** delegate that
+judgment away. Surface the open issues with a one-line severity read and get an
+explicit go, or fix first. Shipping a release with a known open bug from the
+same stream, then being asked "why did you release with known bugs?", is the
+failure this gate prevents.
+
 ### Phase 2: Review and Merge
 
 ```