chore: add release infrastructure and changelog documentation

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,42 @@
+<!-- Thanks for opening a PR! Here are some quick tips:
+If this is your first time contributing, [read our Contributing Guidelines](https://github.com/openfga/.github/blob/main/CONTRIBUTING.md) to learn how to create an acceptable PR for this repo.
+By submitting a PR to this repository, you agree to the terms within the [OpenFGA Code of Conduct](https://github.com/openfga/.github/blob/main/CODE_OF_CONDUCT.md)
+
+If your PR is under active development, please submit it as a "draft". Once it's ready, open it up for review.
+-->
+
+<!-- Provide a brief summary of the changes -->
+
+## Description
+<!-- Provide a detailed description of the changes -->
+#### What problem is being solved?
+
+#### How is it being solved?
+
+#### What changes are made to solve it?
+
+## Changelog
+<!--
+Commit message prefixes (feat:, fix:, etc.) feed the changelog automatically.
+For user-facing changes that need a cleaner description, add a BEGIN_COMMIT_OVERRIDE /
+END_COMMIT_OVERRIDE block here with the text you want in the changelog instead.
+For breaking changes, add a BREAKING CHANGE footer to the commit body.
+See RELEASING.md for details. Leave this section blank if the commit message is sufficient.
+-->
+
+## References
+<!--
+Provide a list of any applicable references here (GitHub Issue, [OpenFGA RFC](https://github.com/openfga/rfcs), other PRs, etc..). We prefer an accompanying issue for all non-trivial PRs.
+
+When referencing links, follow these examples:
+* closes https://github.com/openfga/{repo}/issues/{issue_number}
+* reverts https://github.com/openfga/{repo}/pull/{pr_number}
+* followup https://github.com/openfga/{repo}/pull/{pr_number}
+* blocked by https://github.com/openfga/{repo}/pull/{pr_number}
+-->
+
+## Review Checklist
+- [ ] I have clicked on ["allow edits by maintainers"](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork).
+- [ ] I have added documentation for new/changed functionality in this PR or in a PR to [openfga.dev](https://github.com/openfga/openfga.dev) [Provide a link to any relevant PRs in the references section above]
+- [ ] The correct base branch is being used, if not `main`
+- [ ] I have added tests to validate that the change in functionality is working as expected

CHANGELOG.md

@@ -0,0 +1 @@
+# Changelog

CONTRIBUTING.md

@@ -54,6 +54,8 @@ The user-facing language specification lives in [`docs/language-spec.md`](./docs
 
 Please make sure to follow the existing code style and include tests for your changes. Pull request titles must follow the [Conventional Commits](https://www.conventionalcommits.org/) format, as it is validated in CI.
 
+Commit message prefixes feed the changelog automatically on release. For user-facing changes where the commit message is too terse, add a `BEGIN_COMMIT_OVERRIDE` block to the PR body — see [RELEASING.md](./RELEASING.md#overriding-a-changelog-entry) for details.
+
 ## Getting in Touch
 
 ### Have a question or problem?

RELEASING.md

@@ -0,0 +1,63 @@
+# Releasing
+
+Releases are managed by [release-please](https://github.com/googleapis/release-please). The process is automated — maintainers only need to merge a release PR and confirm a few things beforehand.
+
+## How it works
+
+1. A maintainer triggers the release workflow manually via **Actions → release-please → Run workflow**.
+2. release-please opens or updates a release PR titled `release: vX.Y.Z`, containing an updated `CHANGELOG.md` and a bumped version in `.release-please-manifest.json`.
+3. Merging the release PR tags the commit, which triggers CI to verify the tag matches the manifest and to undraft the GitHub Release.
+
+### Version bump rules
+
+The repo uses `bump-minor-pre-major` and `bump-patch-for-minor-pre-major`, so bumps differ before and after v1.0.0:
+
+| Commit | Before v1.0.0 | v1.0.0 and later |
+|---|---|---|
+| `feat:` | patch | minor |
+| `fix:`, `perf:`, `refactor:` | patch | patch |
+| Any `type!:` or `BREAKING CHANGE:` footer | minor | major |
+
+## Cutting a release
+
+1. Go to **Actions → release-please → Run workflow** and choose the bump type (or supply an explicit version).
+2. release-please opens a PR titled `release: vX.Y.Z` — review the version and changelog.
+3. Approve and merge the PR.
+4. CI will tag the commit, verify versions match, and publish the GitHub Release automatically.
+
+## Changelog entries
+
+release-please builds the changelog from commit messages since the last tag using the sections defined in `release-please-config.json`:
+
+| Prefix | Section | Visible |
+|---|---|---|
+| `feat:` | Added | yes |
+| `fix:` | Fixed | yes |
+| `perf:`, `refactor:` | Changed | yes |
+| `revert:` | Removed | yes |
+| `docs:` | Documentation | yes |
+| `test:`, `ci:`, `chore:` | Miscellaneous | hidden |
+
+### Overriding a changelog entry
+
+When a commit message is too terse or developer-focused, you can override the changelog entry from the PR body. Add this block anywhere in the PR description:
+
+```
+BEGIN_COMMIT_OVERRIDE
+feat: describe the change in user-facing terms
+END_COMMIT_OVERRIDE
+```
+
+release-please uses this text instead of the commit message when building the changelog.
+
+### Breaking changes
+
+Add a `BREAKING CHANGE:` footer to the commit body (not the subject line):
+
+```
+feat!: remove the Foo option
+
+BREAKING CHANGE: the Foo option has been removed. Use Bar instead.
+```
+
+This produces a dedicated breaking changes section in the changelog and a major version bump (minor bump before v1.0.0).