Cut 1.5.0

[SuperInstance]

Master carries the CLI affordance work, the numpy import fix, the CI repairs and the plainsong mcp deprecation — all filed under Unreleased, while version.py still said 1.4.0, which is already on PyPI. So there is nothing publishable: a build from master would either collide with an existing filename or ship this work mislabelled as 1.4.0.

Why a minor and not a patch

Three things changed that a user can observe:

• The CLI accepts --json, -v and -q after the subcommand, where it used to refuse them outright.
• --verbose shows info-level diagnostics, an entire severity previously displayed by no command at all.
• plainsong spec exits non-zero on finding no specs, where it used to exit 0.

That last one is the only thing an upgrader has to read. A script that ran plainsong spec against an install missing its spec files and treated 0 as success will now see a failure — which is the point. That exact silence is what let a broken package through a release.

No notation changes. 6,321 files compile to exactly the music they did in 1.0.0, which the corpus fingerprint checks rather than assumes.

Verified

In every environment CI uses, and one it cannot:

stdlib-only (the 12 platform jobs)	705 tests, 0 errors, 0 failures
pytest job	clean
specs	7/7
ruff check / format --check	clean
corpus fingerprint	6,321 files compile to identical music
verify_release.py --stage wheel	10 passed, 0 failed

The last one is the check the test suite structurally cannot perform: it builds the wheel, installs it into a throwaway virtualenv outside the source tree, and drives the console script from /tmp with PYTHONPATH stripped — so a data file that stopped being packaged fails here rather than after release.

README.md's stated version is bumped to 1.5 alongside, which tests/test_readme_links.py enforces against the tree — it once said "Version 1.0" while PyPI shipped 1.2.0.

Tagging

The release workflow refuses a tag that disagrees with the tree, so after merge:

git checkout master && git pull
grep __version__ plainsong/version.py    # must read 1.5.0
git tag v1.5.0 && git push origin v1.5.0

Tag the commit that carries the bump, not whatever master was when you started — v1.2.0 was created one commit early and the guard caught it.

The blocker this does not fix

Publishing needs a Trusted Publisher configured on PyPI, and there has never been one. All six previous release runs died at the same step with invalid-publisher: valid token, but no corresponding publisher, and every version now on PyPI was uploaded by hand. Until that is set up, tagging builds green and then fails at the publish step.

PyPI → the plainsong project → Publishing → add a publisher: owner SuperInstance, repo plainsong, workflow release.yml, environment left empty (environment: MISSING in the error means exactly that). docs/releasing.md has the long version.

Companion PR: SuperInstance/plainsong-mcp#5 gives the sibling a release workflow it has never had, so 1.0.1 there can ship too.

---

Generated by Claude Code