ci: adopt release-please for monorepo releases

[SnowboardTechie]

Summary

• Fixes [Release] Adopt release-please for monorepo releases #870
• Time to review: 30 minutes

Changes proposed

Replaces the Changesets release workflow with release-please in manifest mode, so the conventional-commit history on main drives versioning and releases for the four published packages.

Why: a forgotten .changeset/*.md ships a change unversioned with nothing to catch it; versions bump the moment any changeset lands, so merges can't be batched into one release; the bump commit is pushed straight to main by CI, which is why both main protection rulesets are off today; and Changesets is Node-only, so the Python SDK carries a stub package.json plus a shell script that greps changeset files to drive the Poetry bump. The options weighed, including keeping Changesets with its official Version-PR action, are recorded in the new ADR.

What changed:

• Added release-please-config.json + .release-please-manifest.json (seeded with the current versions) and a release-please.yml workflow that maintains one Release PR per package and fans out to the publish workflows when a Release PR merges. The existing name@version tag format is preserved exactly.
• Rewired the four cd-deploy-lib-*.yml publish workflows: the release-creation job is gone (release-please owns tag + GitHub release + notes) and the deploy job is now workflow_call from release-please.yml, keeping workflow_dispatch as a manual fallback for re-running a publish against an existing tag. A prefix guard on release_tag protects the manual path against a mistyped ref (replacing the validation the deleted release-notes script used to do). Each publish call receives only the one registry token it uses, declared in the called workflow's workflow_call.secrets, rather than inheriting every repo secret; the deploy jobs also drop an unused id-token: write permission.
• Removed the Changesets machinery: .changeset/, ci-bump-version.yml (including its direct-to-main bump commit that required branch protections off), the release-notes script + .github/release-config/, the vestigial lib/python-sdk/package.json, the root @changesets/* devDependencies, and the tomlq/tomlkit dev-deps that only served the deleted bump script. The Python version is now edited only in pyproject.toml (release-type: python updates it natively).
• Fixed common_grants_sdk/__init__.py, which was stuck at __version__ = "0.1.0" (package is at 0.8.0); release-type: python updates it natively on each release (it probes both the hyphen and underscore forms of the pyproject.toml name, so common_grants_sdk/__init__.py is found without an extra-files entry or an annotation comment). lib/python-sdk/tests/test_version.py now asserts __version__ equals the [tool.poetry] version, so the drift that hid this for several releases fails the Python gate instead of shipping.
• Added ci-pr-title.yml, which validates conventional-commit PR titles against exactly the types release-please treats as releasable, since squashed PR titles are now release-facing. It is a regex over the event payload rather than a third-party action, so the job needs no token scopes. A title whose type has no changelog-sections entry would otherwise merge and then ship unversioned with no error — release-please drops such a commit from the notes and skips the release when the notes come out empty.
• Docs: new ADR 0027 records the decision (ADR 0010 gets a superseded banner); lib/README.md, the per-package DEVELOPMENT.md runbooks, DEPENDENCY_MANAGEMENT.md, and CONTRIBUTING.md describe the new flow.

Context for reviewers

How the new flow works: merge a PR titled fix(...)/feat(...) → release-please opens or updates that package's Release PR → merging the Release PR tags, creates the GitHub release, and publishes to npm/PyPI automatically. chore/ci/test are hidden and don't trigger releases; every other accepted type (fix, perf, revert, docs, refactor, build) cuts a patch, feat a minor, and a ! marker a breaking release (minor while pre-1.0). Publish fan-out happens via workflow outputs in the same run because tags created with GITHUB_TOKEN don't trigger on: release workflows.

Verification:

• release-please release-pr --dry-run against this branch: config parses, all four packages locate their last release from the existing tags, and it would open Version PRs for @common-grants/core 0.3.6, @common-grants/cli 0.3.8, and common-grants-sdk 0.8.1 (the pending fix(deps) advisory work since those tags; lib/ts-sdk correctly has nothing releasable since 0.6.1).
• Full workspace gate (pnpm run ci: core, changelog-emitter, cli, sdk, website) and the Python SDK gate (make checks && make test && make build, 397 tests, wheel builds at 0.8.0) pass locally.

Repo settings (admin):

1. Already applied. Squash-merge settings now use commit title PR_TITLE and message PR_BODY. The previous COMMIT_OR_PR_TITLE let a single-commit PR take its subject from the commit rather than the PR title, which would have bypassed the title check this PR adds.
2. After merge: re-enable the two main branch-protection rulesets (acceptance criterion on [Release] Adopt release-please for monorepo releases #870). This PR removes ci-bump-version.yml, which was the reason they were turned off, and release-please only opens PRs rather than pushing. One direct-to-main push does remain: deps-mapping-repo.yml's scheduled README-diagram commit, which is guarded by a no-op check and has not actually fired since December 2025. It will be blocked once the rulesets are on ("Protect main (pushes)" has no bypass actors), so it is worth converting to a PR-based step separately. "Allow GitHub Actions to create and approve pull requests" is already on and needs to stay on.
3. Optional hardening: a tag-protection ruleset covering @common-grants/*@* and common-grants-sdk@* would require elevated permission to create release-shaped tags (the manual publish fallback trusts tag contents).

Known gap: commits between each package's last tag and this merge that don't follow the conventional format (e.g. #918, #947) are invisible to release-please, so the first Version PRs' changelogs may under-report. Changelog edits pushed to a Release PR branch survive, so the first ones can be hand-amended if it matters.

Additional information

Dry-run output (abridged; run with --target-branch=870-adopt-release-please, so the PR-title scope shows the branch name — on main it reads chore(main): ...):

✔ Building strategies by path
❯ lib/core: node · lib/cli: node · lib/ts-sdk: node · lib/python-sdk: python
❯ Found release for path lib/ts-sdk, @common-grants/sdk@0.6.1
❯ Found release for path lib/python-sdk, common-grants-sdk@0.8.0
❯ Found release for path lib/core, @common-grants/core@0.3.5
❯ found: @common-grants/cli@0.3.7 1f67e30b8153922b67b23d4a0aac54762d6005ff
Would open 3 pull requests
title: chore(870-adopt-release-please): release @common-grants/core 0.3.6
title: chore(870-adopt-release-please): release @common-grants/cli 0.3.8
title: chore(870-adopt-release-please): release common-grants-sdk 0.8.1

[github-actions]

🚀 Website Preview Deployed!

Preview your changes at: https://cg-pr-1051.billy-daly.workers.dev

This preview will be automatically deleted when the PR is closed.

[karinamzalez]

Hi Bryan! It's really neat to see us adopting release-please! I have a few clarifying questions. Some are file-specific but the more generic one:

• should docs only changes be hidden alongside chore/ci/test? -- e.g. a docs(core): fix typo in README PR would publish a new npm release .. I don't think we'd write a changeset for that?
• is missing-release-check.yml still necessary? looks like it's a nightly job that flags tag without a GH release. I think under release-please, tags and releases are created together so it would never fire -- dead code?

[SnowboardTechie]

@karinamzalez thank you for the review! On docs, releases are scoped by path, not by the title's scope, so docs(website): fix typo releases nothing. Inside a package it does release, and I'd keep it: npm ships README.md in the tarball regardless of the files allowlist, so it's a real change to the published artifact. Nothing publishes on the merge either, it just opens or updates a Release PR that sits until we merge it. chore(core): is the lever for internal notes that shouldn't ship. Pushed that to CONTRIBUTING, it wasn't written down.

Good catch on missing-release-check.yml, that's dead and I've deleted it along with check-for-unreleased-tags.sh. It covered the old gap where ci-bump-version.yml pushed the tag on merge and release creation was a separate manual dispatch. release-please does both in one step.