From 1855fe0f4e489b3cdb165ae12976be27544b5950 Mon Sep 17 00:00:00 2001 From: Peter Steinberger Date: Tue, 1 Sep 2026 04:37:00 -0700 Subject: [PATCH] docs: generate changelogs only at release time (#135136) Align contributor guidance with the maintainer-requested release-only rule already recorded in AGENTS.md. Ordinary PRs and merges keep release-note context in PR bodies or commits; takeover permissions remain unchanged. --- CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b331d0323de4..c0b7e43a7197 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -52,8 +52,8 @@ For coordinated change sets that genuinely need more than 20 PRs, join the **#cl - Before implementing a material SQLite or persistent-store change, open or link a maintainer discussion and get the design accepted. See the [database schema review checkpoint](docs/reference/database-schemas.md#review-checkpoint-for-material-changes). - External PRs must describe the user, product, or operational problem in **What Problem This Solves** and include useful validation in **Evidence**. Focused tests, CI results, screenshots, recordings, terminal output, live observations, redacted logs, and artifact links all count. Reviewers will inspect the code, tests, and CI; use the PR body to explain intent and make validation easy to understand. - When ClawSweeper, Barnacle, or a maintainer asks for more context or evidence, edit the PR description instead of only replying in a new comment. Keep **What Problem This Solves**, **Why This Change Was Made**, **User Impact**, and **Evidence** current; a short comment can point reviewers to the update, but the PR body should remain the durable explanation for maintainers and bots. -- Keep PRs takeover-ready: open them from a branch maintainers can push to. For fork PRs, leave GitHub's **Allow edits by maintainers** option enabled so maintainers can finish urgent fixes, changelog entries, or merge prep when needed. If GitHub shows **Allow edits and access to secrets by maintainers**, enable it only when that workflow/secrets access is acceptable and say so in the PR. -- Do not edit `CHANGELOG.md` in contributor PRs. Maintainers or ClawSweeper add the changelog entry when landing user-facing changes. +- Keep PRs takeover-ready: open them from a branch maintainers can push to. For fork PRs, leave GitHub's **Allow edits by maintainers** option enabled so maintainers can finish urgent fixes or merge prep when needed. If GitHub shows **Allow edits and access to secrets by maintainers**, enable it only when that workflow/secrets access is acceptable and say so in the PR. +- Do not edit `CHANGELOG.md` in normal PRs or at merge. Changelogs are generated at release time from merged PRs and commits; keep release-note context in PR bodies or commit messages until then. - Run tests: `pnpm build && pnpm check && pnpm test` - For iterative local commits after running equivalent targeted validation for the touched surface, `git commit --no-verify` skips commit hooks. - For extension/plugin changes, run the fast local lane first: