pi-orchestrator-config 4.20.0 → 4.20.1

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-orchestrator-config",
-  "version": "4.20.0",
+  "version": "4.20.1",
   "description": "Orchestrator pattern for pi: specialist subagents, enforcement, code review loop, workflow commands",
   "keywords": [
     "pi-package"

package/prompts/release.md

@@ -132,8 +132,20 @@ root only).
   <name1>@<v1>[, <name2>@<v2>...]` (keep the `chore: bump version`
   prefix — it is filtered from changelogs).
 - **Phase S6/S7:** release create ONE GitHub RELEASE PER SHIPPED
-  PACKAGE, tag `<name>@<version>` from the bump JSON, same changelog
-  body (including the Shipped packages section), and PASS
+  PACKAGE, tag `<name>@<version>` from the bump JSON. Each release's
+  notes contain ONLY that package's changes: its own version line
+  (`<name> — <old> → <new> (<registry>)`), its own changelog entries
+  from its S3 per-package window, and a compare link whose base you
+  VERIFY before writing it: `git tag -l '<name>@<published>'` first,
+  then `git tag -l 'v<published>'` — if neither tag exists (package
+  never released under either scheme), use the package's `anchor`
+  commit SHA from the plan JSON as the base
+  (`compare/<anchor-sha>...<name>@<version>`; GitHub compare accepts
+  any ref). NEVER write a compare link with an unverified ref, and
+  NEVER list other packages in a
+  release's notes — a release that ships only myk-pi-tools must not
+  claim pi-orchestrator-config shipped; cut-level context lives in the
+  bump PR, not in per-package releases. PASS
   `--title "<name> <version>"` explicitly — without it the release
   title defaults to the raw `name@version` tag. Tags are per-package
   and cannot collide — there is no repo-wide `v<TAG>` in scoped mode.