chore: bump version to 0.5.0

[dangrondahl]

Version bump only — package.json and package-lock.json. Merge this, then tag v0.5.0 on main to trigger the release.

What ships

One user-facing change since v0.4.0: the regenerated catalog from #18.

• list_flows gains space_id and tag query filters
• include_scaling is marked deprecated
• list_artifact_approvals is removed — the endpoint was retired upstream

Everything else since v0.4.0 is CI, docs, and repo hygiene, none of which reaches the npm tarball. The README does ship, so the new beta notice and write-action caution go out with this.

Why minor, not patch

An action disappearing from the catalog is user-visible: anything calling list_artifact_approvals via execute_read_action stops resolving. Pre-1.0, a minor bump is the conventional signal for that, even though the removal originated upstream rather than here.

Notes

• manifest.json still holds its 0.0.0-replaced-at-build-time placeholder, injected by the pack script — untouched, as intended.
• Both package.json and package-lock.json were updated via npm version --no-git-tag-version, so the lockfile doesn't drift.
• Tests pass locally: 8 files, 65 tests.
• This should be the first release carrying npm provenance, now that the repo is public and ci: re-enable npm provenance now that the repo is public #35 has landed. Verify after publish with npm view @kosli/mcp-server dist.attestations — it returned null for 0.4.0.

[claude]

Claude finished @dangrondahl's task in 3m 0s —— View job

---

Review: version bump 0.4.0 → 0.5.0

Verified the diff and every factual claim in the PR body. This is a clean release bump — nothing architectural is touched, so the Phase 1 design invariants (three tools, generated catalog, non-throwing KosliClient, compact JSON.stringify, org fallback, User-Agent, ESM .js imports, strict: true) are all trivially intact. Two minor notes, neither blocking.

Claims I checked out

Claim	Verdict
manifest.json placeholder untouched	✅ still 0.0.0-replaced-at-build-time
Only the catalog change is user-facing	✅ files: ["dist"], so the CI/SECURITY.md/CLAUDE.md changes don't reach the tarball (README does — npm always includes it)
list_flows gains space_id + tag	✅ both added as repeatable query params
include_scaling deprecated	✅ deprecated: true on both the create- and update-environment bodies
list_artifact_approvals removed	✅ removed, and grep finds no dangling references anywhere — not in src/, test/fixtures/catalog-subset.json, or the README
Conventional Commits	✅ title and the single commit both chore:

The minor-not-patch reasoning is right, and for the reason given: an action ID vanishing from the catalog is observable through execute_read_action regardless of who caused it upstream. Pre-1.0 that's a minor.

1. Lockfile name is still drifted (minor)

Details inline. package-lock.json says @kosli-dev/mcp-server; package.json says @kosli/mcp-server. The version drift is fixed here, the name drift isn't — a npm install --package-lock-only would normalise both.

2. README pins @0.4.0 as its example (minor)

README.md:6 — the beta notice that ships with this release tells users to pin the previous version:

If you need stability, pin a version — e.g. npx -y @kosli/mcp-server@0.4.0

Since the README rides along in the tarball, 0.5.0 would publish advice pointing one release back. Either bump it to @0.5.0 here, or drop the concrete number so it stops being a per-release chore. Fix this →

Suggestion for later (not this PR)

release.yml:32-39 verifies the tag against package.json only. That's exactly why the lockfile sat at 0.1.0 across four releases without anyone noticing. Adding the lockfile to that same check would make the drift fail loudly at tag time instead of silently. I can't edit files under .github/workflows/ (GitHub App permissions), so flagging rather than implementing.

Nice work

• The PR body does the thing release PRs usually skip: separates what actually ships from what merely landed, and justifies the version choice instead of asserting it. The dist.attestations verification step for the first provenance-carrying publish is a good follow-through on ci: re-enable npm provenance now that the repo is public #35.
• Catching that the removed action needed a version signal at all — it would have been easy to call a catalog regen a patch.

Not verified

I couldn't run npm ci, npm run build, or npm test — npm isn't in my allowed tools for this run, so I'm taking the "8 files, 65 tests" pass on trust. Nothing in a two-line version bump should affect it, and CI covers it anyway. My repo checkout is also shallow, so I compared trees at v0.4.0..HEAD rather than reading the commit list.

--- · branch chore/bump-0.5.0

[claude]

The version drift is fixed here, but the lockfile's name is still drifted: it says @kosli-dev/mcp-server (here and again at line 8) while package.json declares @kosli/mcp-server. So the PR note "the lockfile doesn't drift" is only half true after this change.

Two things this suggests:

1. The bump probably didn't go through a real lockfile reify — a full npm install --package-lock-only rewrites the root packages[""] entry from package.json, which would have normalised the name along with the version. Worth running it and committing the result so both name fields land on @kosli/mcp-server.
2. Otherwise this stays a latent diff: the next PR that touches a dependency will regenerate the lockfile and pick up an unrelated rename in its diff.

Harmless for publishing (npm publish reads package.json, and npm ci has clearly tolerated the mismatch through four releases), so this is cleanliness, not a blocker.

Fix this →