[brawer]

What

Implements #804: replaces the version-bump half of the release process
(scripts/cut-release.sh) with release-please,
per the decision on that issue — ! stays output-schema-breaking here
(conflated.parquet), not API-breaking, exactly as CONTRIBUTING.md
already documents.

• release-please-config.json / .release-please-manifest.json —
  bump-minor-pre-major + bump-patch-for-minor-pre-major reproduce
  this project's existing pre-1.0 rule from RELEASING.md's "Choosing
  the version number" exactly: a ! commit bumps minor, everything
  else (feat:, fix:, chore:, ...) bumps patch. There's no gap here
  pre-1.0 — see the new "How release-please's version bumps map to this
  rule" section in RELEASING.md.
• .github/workflows/release-please.yml — runs on every push to
  main; keeps one release PR open, then tags + publishes the release
  once that PR is merged (a human still does the merging — no
  automerge). Authenticates as the account-wide brawer-release-bot
  GitHub App (already used the same way by osmviews/osmviews-rs/
  osmviews-py) rather than a PAT — see below.
• CHANGELOG.md — bootstrapped fresh from here forward; earlier
  releases stay on the Releases page.
• scripts/cut-release.sh removed — its only remaining job
  (verification) is scripts/verify-release.sh, unchanged, still run by
  hand after a release publishes.
• docs/RELEASING.md, docs/CONTRIBUTING.md, scripts/README.md,
  pr-title-lint.yml comments updated to match.

⚠️ Manual step needed before this works: finish installing the App

The workflow needs a real identity, not the default GITHUB_TOKEN —
GitHub deliberately blocks a GITHUB_TOKEN-authored PR from triggering
further workflow runs (anti-recursion), so test.yml's
pull_request-triggered required check would never run against the
release PR, and it could never clear the branch ruleset to be merged.

Rather than a new PAT, this reuses brawer-release-bot, the App
already installed on your other three repos. The RELEASE_PLEASE_APP_CLIENT_ID
repo variable is already set (same value as the other repos). Still
needed, both one-time, documented in RELEASING.md's "Setting up the
release-please App":

1. On the App's installation page, add brawer/osmdiffs to its
   repositories.
2. Generate a new private key for the App (it can hold several at
   once) and set it as the RELEASE_PLEASE_APP_PRIVATE_KEY secret here:

   gh secret set RELEASE_PLEASE_APP_PRIVATE_KEY --repo brawer/osmdiffs < path/to/key.pem

Until both exist, the workflow guards itself with
if: vars.RELEASE_PLEASE_APP_CLIENT_ID != '' and simply skips rather
than failing on every push to main.

Other things worth double-checking once the first release PR appears

• That its commit shows as "Verified" (required by the repo's
  required_signatures ruleset) — App-authenticated commits made via
  the GitHub API, not git push, are auto-signed by GitHub, the same
  way Dependabot's commits already pass this; should just work the same
  way it evidently already does for the osmviews repos, but worth a
  glance the first time.
• That merging it through the merge queue behaves like any other PR.
• That the GitHub Release it creates gets the same immutable-tag
  treatment as before (it should — same underlying gh/API tag +
  release mechanism).

Not changed

• .github/release.yml — kept as a fallback for GitHub's own
  auto-generated notes (gh release create --generate-notes), no longer
  the primary changelog. Low cost to keep, and there's no reason to
  force a same-PR decision on it.
• pr-title-lint.yml's auto-label job — still labels PRs from their
  title; still useful for that fallback and for the GitHub UI generally,
  even though release-please reads PR titles directly rather than these
  labels.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GbC1fdZjJwiGmmjWqTcmJX