From a3efbb8065e5689d5783af4225f399eee2dd5ab0 Mon Sep 17 00:00:00 2001 From: Hazel Granados Date: Wed, 21 Oct 2026 22:21:16 -0500 Subject: [PATCH 1/2] docs(agents): credit contributors in release notes Hand-written release notes keep the generated credits: every outside contributor's pull requests by @-name, and first contributions. v0.2.0 dropped the credits for #34, #35 and #36 when its notes were rewritten; they're back in a Thanks section. --- AGENTS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/AGENTS.md b/AGENTS.md index a21c88b..d1e9289 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -51,4 +51,5 @@ Everything must run the same in PowerShell and bash: use `node` scripts, never b - Conventional Commits, small and atomic. No AI attribution or co-author trailers. - `main` is protected: every change reaches it through a pull request whose CI (`check` and `e2e`) passes, with no direct pushes, even by admins. Work on a branch named for the change (`data/add-conventions`, `docs/listing-rules`), one pull request per issue or per change. Merge with **Rebase and merge** so each commit lands on `main` as written. - Tagging and publishing a release happen only at a milestone gate the maintainer approved. Versioning rules are in `ROADMAP.md` (2026-10-18), steps in `docs/MAINTENANCE.md`. +- Release notes credit contributors. When you rewrite GitHub's generated notes by hand, keep its credits: thank everyone outside the project by @-name with their pull requests, and say when it's their first contribution. v0.2.0 went out without crediting #34, #35 and #36 because its notes were rewritten without them. - Do not push a branch, open or merge a pull request, create or change the GitHub repo, or deploy without the maintainer's explicit go-ahead. A "push" covers pushing the branch and opening its pull request; merging needs its own go-ahead. From 0384fbeb8b98b883a5e6b6aeb662180282708b20 Mon Sep 17 00:00:00 2001 From: Hazel Granados Date: Wed, 21 Oct 2026 22:24:01 -0500 Subject: [PATCH 2/2] docs(agents): keep release notes short and easy to scan The maintainer prefers short release notes for every release: a one-line summary, a three-step Try it, one-line bullets, a Heads-up and Thanks, and nothing the README already says. --- AGENTS.md | 1 + 1 file changed, 1 insertion(+) diff --git a/AGENTS.md b/AGENTS.md index d1e9289..fd9c441 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -52,4 +52,5 @@ Everything must run the same in PowerShell and bash: use `node` scripts, never b - `main` is protected: every change reaches it through a pull request whose CI (`check` and `e2e`) passes, with no direct pushes, even by admins. Work on a branch named for the change (`data/add-conventions`, `docs/listing-rules`), one pull request per issue or per change. Merge with **Rebase and merge** so each commit lands on `main` as written. - Tagging and publishing a release happen only at a milestone gate the maintainer approved. Versioning rules are in `ROADMAP.md` (2026-10-18), steps in `docs/MAINTENANCE.md`. - Release notes credit contributors. When you rewrite GitHub's generated notes by hand, keep its credits: thank everyone outside the project by @-name with their pull requests, and say when it's their first contribution. v0.2.0 went out without crediting #34, #35 and #36 because its notes were rewritten without them. +- Release notes are short and easy to scan (the maintainer's preference): a bold one-line summary, a three-step "Try it", one-line bullets that start with a bold label, a "Heads-up" for this release's caveats, then "Thanks". Leave out what the README already says, such as what the site is and how to run it. v0.2.0's notes are the model. - Do not push a branch, open or merge a pull request, create or change the GitHub repo, or deploy without the maintainer's explicit go-ahead. A "push" covers pushing the branch and opening its pull request; merging needs its own go-ahead.