fix(entries): four ferrflow fixes from the coverage pass

entries/2026-07-16-ferrflow-migrate-semantic-release.md

@@ -17,7 +17,7 @@ ferrflow migrate --from semantic-release
 
 It maps what has a FerrFlow equivalent:
 
-- `tagFormat: "v${version}"` → `tagTemplate: "v{{version}}"`
+- `tagFormat: "v${version}"` → `tagTemplate: "v{version}"`
 - `branches` → FerrFlow channels: `main`/`master` become the stable line, a `prerelease` branch becomes a channel
 - `@semantic-release/changelog` → the package's `changelog` path
 - `@semantic-release/exec` → hooks (`prepareCmd` → `preBump`, `publishCmd` → `postPublish`, and the rest)

entries/2026-09-28-ferrflow-floating-tag-backward.md

@@ -0,0 +1,12 @@
+---
+title: 'FerrFlow: a hotfix no longer drags a floating tag backward'
+summary: 'Releasing 1.4.2 after 1.5.0 silently moved v1 back to 1.4.2. The guard meant to stop that never fired. It does now: the release stops before anything is pushed, and --force lets the alias move.'
+date: 2026-09-28T10:00:00Z
+product: ferrflow
+type: fix
+prLink: https://github.com/FerrLabs/FerrFlow/pull/1226
+---
+
+Floating tags such as `v1` or `v1.5` are supposed to only move forward: when a release on an older line would point them at a lower version, FerrFlow stops the release, and only `--force` lets the alias move backward, with a warning. That check read the version from the alias tag's message, which git hands back with a trailing newline, so parsing it failed and the check concluded there was nothing to protect.
+
+In practice, cutting a hotfix on a maintenance branch moved the major alias back to the hotfix, and anyone pinned to `v1` got the older code. The check now works as documented, which changes what a hotfix pipeline sees: a job that used to succeed on a maintenance line now fails at `ferrflow release` with "Floating tag v1 would move backward", before anything is pushed. If you do want the alias to follow the hotfix, add `--force` to that job.

entries/2026-09-28-ferrflow-helm-chart-name.md

@@ -0,0 +1,12 @@
+---
+title: 'FerrFlow: the Helm publisher reads the right chart name'
+summary: 'In a Chart.yaml listing dependencies or maintainers before the chart name, the Helm publisher could take a dependency name for the chart and check or push the wrong reference. Only the top-level name key counts now.'
+date: 2026-09-28T10:10:00Z
+product: ferrflow
+type: fix
+prLink: https://github.com/FerrLabs/FerrFlow/pull/1231
+---
+
+The `helm` publisher reads the chart name from `Chart.yaml` to build the OCI reference it checks and pushes. It matched the first `name:` on any line, indented or not, so a chart whose `dependencies:` or `maintainers:` block came before its own `name:` was treated as the dependency: the "already published" check looked at the wrong reference, and the push went there too.
+
+The publisher now only reads the top-level `name:` key, whatever order the file is written in. Charts that put `name:` first were never affected.

entries/2026-09-28-ferrflow-migrate-tag-template.md

@@ -0,0 +1,23 @@
+---
+title: 'FerrFlow: migrating from semantic-release keeps your tags'
+summary: 'ferrflow migrate turned tagFormat "v${version}" into tagTemplate "v{{version}}", which FerrFlow renders as v{1.2.0}. It now writes "v{version}", so the migrated config finds the tags semantic-release created.'
+date: 2026-09-28T10:05:00Z
+product: ferrflow
+type: fix
+prLink: https://github.com/FerrLabs/FerrFlow/pull/1229
+docsLink: https://ferrflow.com/docs/reference/cli
+---
+
+`ferrflow migrate` converts a semantic-release `tagFormat` into a FerrFlow `tagTemplate`. The conversion wrote the placeholder with doubled braces, `{{version}}`, while FerrFlow templates use single ones. A config migrated from `tagFormat: "v${version}"` therefore rendered tags like `v{1.2.0}`: the first release after migrating found none of the existing tags and started over.
+
+The conversion now writes `{version}`. If you already migrated, check the `ferrflow.json` it wrote for `{{version}}` and replace it with `{version}`:
+
+```json
+{
+  "workspace": {
+    "tagTemplate": "v{version}"
+  }
+}
+```
+
+The migration table in the CLI reference and in the entry that announced `ferrflow migrate` showed the same wrong output and have been corrected.

entries/2026-09-28-ferrflow-padded-versions.md

@@ -0,0 +1,12 @@
+---
+title: 'FerrFlow: versions read from files never carry stray whitespace'
+summary: 'A version written with padding or a line break inside its quotes came back with the whitespace attached and could not become a tag. package.json, Cargo.toml, pyproject.toml and Chart.yaml read with the helm format now trim it; mix.exs, gemspec, Gradle and Package.swift reject it with a clear error.'
+date: 2026-09-28T10:15:00Z
+product: ferrflow
+type: fix
+prLink: https://github.com/FerrLabs/FerrFlow/pull/1218
+---
+
+Several version file readers returned the quoted value exactly as written. `"version": " 1.2.0 "` in `package.json`, or a `version:` literal in `mix.exs` that spanned a line break, produced a version with whitespace in it, and the release then failed at `git tag` with an error about invalid ref names.
+
+Where the version sits in a delimited string (`package.json`, `Cargo.toml`, `pyproject.toml`, and `Chart.yaml` read with the `helm` format that `ferrflow init` detects), the padding is unambiguous and is now trimmed, so those files keep working. Where the version is found by pattern (`mix.exs`, `.gemspec`, Gradle, `Package.swift`), a padded literal is now reported as "no version found" instead of being guessed at, so you can fix the file before anything is tagged.