automation: the changelog is missing CLI releases v2.44.0 and v2.45.0 #439

The CLI reference has already been regenerated from a release the changelog never recorded, so two CLI releases shipped with nothing telling readers what changed in them.

Evidence

client_reference/overview.md:7:

This reference was generated from Kosli CLI v2.45.0.

changelog/index.mdx:7 — the newest CLI entry in the file:

<Update label="September 18, 2026" description="v2.43.1" tags={["CLI"]}>

update-cli-docs.yml runs on every CLI release, so the reference being at v2.45.0 is direct evidence that v2.44.0 and v2.45.0 both shipped. Neither appears in changelog/index.mdx:

$ grep -c 'v2\.44\.0\|v2\.45\.0' changelog/index.mdx
0

The gap is only in the CLI stream. The reference regeneration and the changelog are driven by different automation (update-cli-docs.yml versus .mintlify/workflows/update-changelog.md), and only the first one fired.

Why it matters

The changelog is the record of what shipped, and it is the only place a reader learns about breaking changes. v2.37.0 and v2.40.0 both carried breaking changes in this same window (changelog/index.mdx:241 and :99), so a silently skipped CLI release is not a safe thing to assume is harmless. A reader on v2.43.1 who upgrades to v2.45.0 has no way to know what they are taking on.

It also means the reference and the changelog disagree about which version the site describes, which undermines both.

What a fix looks like

1. Write the two missing entries from the upstream release notes for kosli-dev/cli v2.44.0 and v2.45.0, following the existing <Update> format and the rules in .mintlify/workflows/update-changelog.md.
2. Work out why the workflow did not fire for them, and close that hole. Worth checking whether the trigger can miss a release, and whether a run can fail without anyone noticing.
3. Consider a cheap guard: compare the version in client_reference/overview.md against the newest CLI <Update> in changelog/index.mdx and fail if the reference is ahead. That is a few lines in pr-quality.yml and it would have caught this. It generalizes to the same question for the Terraform Provider stream.

Related, not duplicate

• chore: harden the update-changelog workflow against the review findings it keeps repeating #389 hardens the content of changelog entries that do get written. This is about entries that never get written at all.
• automation: add kosli-dev/mcp-server to the update-changelog workflow #360 adds a product to the workflow. Also not this.

Found by the monthly doc-structure audit, step 4 (changelog coverage).