ci: adopt release-please for commit-driven versioning

.github/CODEOWNERS

@@ -7,8 +7,9 @@
 /go/cmd/configure/   @vngcloud/platform
 /go/main.go          @vngcloud/platform
 
-# Shared docs, changelog, and CI — additive but cross-team; platform reviews.
-/.changes/           @vngcloud/platform
+# Shared release/CI config and docs — cross-team; platform reviews.
+/release-please-config.json      @vngcloud/platform
+/.release-please-manifest.json   @vngcloud/platform
 /.github/            @vngcloud/platform
 /mkdocs.yml          @vngcloud/platform
 /docs/development/  @vngcloud/platform

.github/PULL_REQUEST_TEMPLATE.md

@@ -12,8 +12,8 @@ Brief description of what this PR does.
 
 ## Checklist
 
-- [ ] Tests added/updated and passing (`python -m pytest tests/ -v`)
-- [ ] Changelog entry added (`./scripts/new-change`)
+- [ ] Tests added/updated and passing (`cd go && go test ./...`)
+- [ ] PR title is a Conventional Commit (`feat:`/`fix:`/`feat!:`) — drives the release
 - [ ] Documentation updated (if applicable)
 - [ ] Code follows existing patterns
 

.github/workflows/pr-title.yml

@@ -0,0 +1,20 @@
+name: Conventional Commits title
+
+# release-please derives the version bump and CHANGELOG from commit messages.
+# We squash-merge, so the PR title becomes the commit message — it must be a
+# valid Conventional Commit (feat:, fix:, docs:, chore:, feat!:, ...).
+
+on:
+  pull_request:
+    types: [opened, edited, synchronize]
+
+permissions:
+  pull-requests: read
+
+jobs:
+  title:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: amannn/action-semantic-pull-request@v5
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/release-please.yml

@@ -0,0 +1,40 @@
+name: Release Please
+
+on:
+  push:
+    branches: [main]
+
+permissions:
+  contents: write
+  pull-requests: write
+
+jobs:
+  release-please:
+    runs-on: ubuntu-latest
+    outputs:
+      release_created: ${{ steps.rp.outputs.release_created }}
+      tag_name: ${{ steps.rp.outputs.tag_name }}
+    steps:
+      # Optional fine-grained PAT (contents: write, pull-requests: write). With a
+      # PAT the release PR's required checks start automatically; with the default
+      # GITHUB_TOKEN you must close & reopen the release PR once to kick checks.
+      - uses: googleapis/release-please-action@v4
+        id: rp
+        with:
+          token: ${{ secrets.RELEASE_PLEASE_TOKEN || github.token }}
+          config-file: release-please-config.json
+          manifest-file: .release-please-manifest.json
+
+  # When release-please cuts a release (release PR merged), build the binaries and
+  # attach them to the just-created GitHub Release. Done in-run so we don't depend
+  # on the release tag triggering the tag-push workflow (GITHUB_TOKEN-created tags
+  # do not trigger push workflows).
+  build-release:
+    needs: release-please
+    if: ${{ needs.release-please.outputs.release_created == 'true' }}
+    uses: ./.github/workflows/release.yml
+    with:
+      tag: ${{ needs.release-please.outputs.tag_name }}
+    permissions:
+      contents: write
+    secrets: inherit

.github/workflows/release.yml

@@ -12,6 +12,12 @@ on:
       version:
         description: 'Version to release (e.g. 0.2.0)'
         required: true
+  workflow_call:
+    inputs:
+      tag:
+        description: 'Release tag to build and attach binaries to (e.g. v1.7.0)'
+        required: true
+        type: string
 
 permissions:
   contents: write
@@ -70,9 +76,18 @@ jobs:
           path: dist/
           merge-multiple: true
 
-      - name: Create GitHub Release
-        uses: softprops/action-gh-release@v2
-        with:
-          tag_name: ${{ github.ref_name }}
-          generate_release_notes: true
-          files: dist/grn-*
+      - name: Attach binaries to the release
+        env:
+          GH_TOKEN: ${{ github.token }}
+          # tag comes from the workflow_call input; otherwise the pushed tag ref.
+          TAG: ${{ inputs.tag || github.ref_name }}
+          REPO: ${{ github.repository }}
+        run: |
+          set -euo pipefail
+          if gh release view "$TAG" --repo "$REPO" >/dev/null 2>&1; then
+            # Release already exists (e.g. created by release-please) — attach binaries.
+            gh release upload "$TAG" dist/grn-* --clobber --repo "$REPO"
+          else
+            # Manual tag push / dispatch — create the release with generated notes.
+            gh release create "$TAG" dist/grn-* --generate-notes --repo "$REPO"
+          fi

.release-please-manifest.json

@@ -0,0 +1,3 @@
+{
+  ".": "1.6.0"
+}

CLAUDE.md

@@ -139,8 +139,11 @@ GOOS=windows GOARCH=amd64 go build -o grn-windows-amd64.exe .
 
 - **Do not auto commit/push** — only change source code, user will ask for commit/push
 - **Main branch is protected** — must use PR
-- **Changelog**: `./scripts/new-change` for every change
-- **Release**: `./scripts/bump-version minor` → `git push && git push --tags`
+- **Versioning/CHANGELOG are automated by release-please** — never edit the version
+  (`go/cmd/root.go`) or `CHANGELOG.md` by hand
+- **PR titles are Conventional Commits** (`feat:`/`fix:`/`feat!:`) — PRs are squash-merged,
+  so the title becomes the release commit release-please reads
+- **Release**: merge the `chore: release main` PR → tags `vX.Y.Z` + GitHub Release + binaries
 
 ## Documentation update rule
 
@@ -157,7 +160,6 @@ GOOS=windows GOARCH=amd64 go build -o grn-windows-amd64.exe .
 - `CLAUDE.md`
 - `CONTRIBUTING.md`
 - `docs/development/contributing.md` and `docs/development/architecture.md` (adding services/commands)
-- `./scripts/new-change` — changelog fragment
 
 > Note: `docs/superpowers/` (design specs/plans) is local-only and git-ignored —
 > never commit it to this public repo.

CONTRIBUTING.md

@@ -41,31 +41,37 @@ CGO_ENABLED=0 go build -o grn .
 ./grn vks <your-command> --help
 ```
 
-### 3. Add a changelog entry
+### 3. Versioning & changelog are automated (release-please)
 
-Every PR should include a changelog fragment:
+**Do not edit the version or CHANGELOG by hand.** [release-please](https://github.com/googleapis/release-please)
+derives the version bump and `CHANGELOG.md` from commit messages. Because PRs are
+**squash-merged**, the **PR title becomes the commit message**, so it must be a
+valid [Conventional Commit](https://www.conventionalcommits.org/) — this is
+enforced by the `Conventional Commits title` check.
 
-```bash
-./scripts/new-change -t feature -c vks -d "Add your feature description"
+```
+feat(vks): add describe-events command        # minor bump
+fix(auth): fix token refresh race condition   # patch bump
+feat!: drop deprecated --foo flag             # breaking (see note)
+docs(readme): update installation             # no release
 ```
 
-Change types: `feature`, `bugfix`, `enhancement`, `api-change`
-
-### 4. Commit and push
+Bump rules: `fix:` → patch, `feat:` → minor, `feat!:`/`BREAKING CHANGE:` → major.
+Getting a wrong bump? Fix the PR title — never touch the version file.
 
-Follow [Conventional Commits](https://www.conventionalcommits.org/):
+### 4. Create a Pull Request
 
-```
-feat(vks): add describe-events command
-fix(auth): fix token refresh race condition
-docs(readme): update installation instructions
-```
+- PR to `main`; use a Conventional Commit title (the `Conventional Commits title`
+  check gates it).
+- CI (`Run Tests`) must pass before merge.
+- **Squash-merge** so the PR title lands as the release commit.
 
-### 5. Create a Pull Request
+### 5. Releasing
 
-- PR to `main` when release-ready
-- CI must pass before merge
-- At least 1 approval required
+release-please opens/refreshes a `chore: release main` PR that bumps the version
+(in `go/cmd/root.go`) and updates `CHANGELOG.md`. Merge that PR to publish: it
+tags `vX.Y.Z`, creates the GitHub Release, and the release workflow attaches the
+built binaries.
 
 ## Adding a New Command
 

docs/development/contributing.md

@@ -24,7 +24,9 @@ go build -o grn .
 7. (Optional) Register flag value completion — see [Architecture](architecture.md#shell-completion)
 8. Document it: create `docs/commands/<service>/<command-name>.md`, add it to the
    command index table and to the `mkdocs.yml` nav
-9. Add a changelog fragment: `./scripts/new-change -t feature -c <service> -d "..."`
+
+The changelog/version are automated by release-please from your Conventional
+Commit PR title — no manual changelog step.
 
 ## Adding a new service