pi-orchestrator-config 4.19.0 → 4.20.1

package/README.md

@@ -806,7 +806,7 @@ PI_PIDIFF_ENABLE=false pi
 | `myk-pi-tools pr claude-md`            | Fetch `CLAUDE.md` and `AGENTS.md` content for a PR's repository                                                                                |
 | `myk-pi-tools release create`          | Create a GitHub release with changelog                                                                                                         |
 | `myk-pi-tools release plan`            | Scoped-release plan: which packages changed since their last publish (per-package registry-anchored diff windows). Detection only — no proposed versions. Read-only; requires `release-map.toml` at the repo root — without it, reports lockstep mode and changes nothing (issue #965) |
-| `myk-pi-tools release bump-scoped`     | Bump ONLY the affected packages' version files. Versions are ALWAYS explicit: `--set NAME=VERSION` per affected package (the versions the LLM/user decided in the `/release` flow) or a global `--version X.Y.Z` — the plan never proposes versions. Repo tag = highest version and must exceed the latest existing repo tag. Versions are validated (strict x.y.z, no leading zeros, strictly greater than the registry-published version). Errored packages, undetected version files, or partially-updatable manifests abort before or at the first bad write. Requires `release-map.toml` — without it, exit 1 (use `bump-version` for lockstep) (issue #965) |
+| `myk-pi-tools release bump-scoped`     | Bump ONLY the affected packages' version files. Versions are ALWAYS explicit: `--set NAME=VERSION` per affected package (the versions the LLM/user decided in the `/release` flow) or a global `--version X.Y.Z` — the plan never proposes versions. Each package versions from its own registry history (no global repo-tag guard — no forced jumps for long-skipped packages); tags are per-package `<name>@<version>`. Versions are validated (strict x.y.z, no leading zeros, strictly greater than the registry-published version). Errored packages, undetected version files, or partially-updatable manifests abort before or at the first bad write. Requires `release-map.toml` — without it, exit 1 (use `bump-version` for lockstep) (issue #965) |
 | `myk-pi-tools db`                      | Review database query commands                                                                                                                 |
 | `myk-pi-tools reviews`                 | Review handling commands (fetch, poll, address, post, store, store-session)                                                                   |
 | `myk-pi-tools reviews poll`            | Poll a PR for review comments until approved or actionable — `--source qodo` reads findings through the `qodo` CLI (structured, with spans and authoritative open/closed status) when the binary is installed and authenticated, and falls back to the GitHub sticky-comment scrape otherwise. Read-only: replies are always posted as GitHub comments via `reviews address` |
@@ -840,15 +840,24 @@ myk-pi-tools release plan --force-package pi-docsite
 - Global excludes configured in the map (e.g. `tests/`) never trigger a release by themselves;
   multi-registry packages must agree across their registries or they are reported as errored,
   never silently skipped.
+- The plan also reports **unmapped changes**: files changed since the last repo tag that
+  belong to no package, no exclude, and no container rebuild-path. A change that ships
+  nowhere silently is the broken failure mode — the operator maps the path or consciously
+  accepts it as release-inert.
 - The container image is reported as needing a rebuild when any package ships or a `rebuild-paths` entry changed since the last repo tag.
 
 `myk-pi-tools release bump-scoped` performs the scoped version bump: only affected
-packages' version files are written, the repo tag is the highest version, and any errored
-package or undetected version file aborts before a single write. The plan detects WHAT
-changed and nothing more — no proposed versions, no bump types. The next versions are decided
-by the LLM and the user in `/release` and passed as `--set NAME=VERSION` (without `--set` or
-`--version`, `bump-scoped` refuses to run). `/release X.Y.Z` overrides every affected package
-to that version. See the Scoped Mode Check in the release prompt.
+packages' version files are written, and any errored package or undetected version file
+aborts before a single write. Each package versions from **its own registry history** —
+there is deliberately no global repo-tag guard, so a package skipped for several releases
+takes the next version after its own last publish (never a forced jump past the global tag
+sequence). Tags are **per package** (`<name>@<version>`) and cannot collide. The plan
+detects WHAT changed and nothing more — no proposed versions, no bump types. The next
+versions are decided by the LLM and the user in `/release` and passed as
+`--set NAME=VERSION` (without `--set` or `--version`, `bump-scoped` refuses to run).
+`/release X.Y.Z` overrides every affected package to that version. Each shipped package
+gets its own GitHub release tagged `<name>@<version>`. See the Scoped Mode Check in the
+release prompt.
 
 Without a `release-map.toml`, `release plan` reports lockstep mode and nothing else changes —
 the generic release flow is untouched.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pi-orchestrator-config",
-  "version": "4.19.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

@@ -75,13 +75,26 @@ root only).
 **If PRESENT:** run the SCOPED flow instead of Phases 2–5:
 
 - **Phase S2 — Detection:** `myk-pi-tools release plan --json`. If any
-  package is errored, show the errors and abort — do not bump. If no
-  packages are affected, report "nothing to release — no package changed
-  since its last publish" and stop. The plan only reports WHICH packages
-  changed and their published versions — it does NOT decide the next
-  versions.
+  package is errored, show the errors and abort — do not bump. The plan
+  only reports WHICH packages changed and their published versions — it
+  does NOT decide the next versions. ALSO inspect `unmapped_changes` in
+  the plan JSON — ALWAYS, before any other decision: files that changed
+  but belong to no package, exclude, or container rebuild-path. If
+  non-empty, show them to the user as text IMMEDIATELY (a changed file
+  that ships nowhere silently is the broken failure mode) — map the
+  path (edit `release-map.toml`) or consciously accept it as
+  release-inert. This display is NOT part of Phase S4 approval: it
+  happens even when an explicit version was given and even when no
+  packages are affected. Then, if no packages are affected, report
+  "nothing to release — no package changed since its last publish"
+  (plus the unmapped list, if any) and stop.
 - **Phase S3 — Changelog + version proposals:** generate the changelog
-  with the standard Phase 3 rules. Then, for EACH affected package, YOU
+  with the standard Phase 3 rules, EXCEPT the commit window: scoped
+  repos have per-package tags (`name@version`), so do NOT anchor the
+  changelog on `release info`'s `last_tag` or its version-branch tag
+  filter (`v2.10.*` inference finds no per-package tags and would treat
+  the run as a first release) — anchor on each affected package's own
+  `anchor` from the plan JSON. Then, for EACH affected package, YOU
   (the LLM) decide the next version. IMPORTANT: a package's history
   reaches back to ITS last publish, which may predate the last repo tag
   — do NOT rely on the changelog alone. For each affected package run
@@ -92,29 +105,51 @@ root only).
   just subjects — a `BREAKING CHANGE:` footer lives in the commit body
   and forces major even under a `feat:`/`fix:` subject. The plan does NOT propose versions — you
   do. An explicit version argument (`/release X.Y.Z`) instead sets EVERY
-  affected package to that version, skipping per-package decisions. The
-  repo tag is the HIGHEST proposed version.
-- **Phase S4 — Approval:** skip this phase entirely if an explicit
+  affected package to that version, skipping per-package decisions.
+  Each package versions from ITS OWN registry history only — a package
+  skipped for N releases takes the next version after its own last
+  publish (e.g. 4.18.0 → 4.19.0), never a jump past the global tag
+  sequence.
+- **Phase S4 — Approval:** skip the `ask_user` entirely if an explicit
   version was provided in the raw arguments (same contract as lockstep
-  Phase 4). Otherwise: show the changelog, the per-package version
-  proposals (`current → proposed`), AND the plan's skipped-packages
-  list as text — the human validates the detection on every scoped
-  release (a package wrongly skipped is the broken failure mode). Then
-  a short `ask_user`: `Release v<TAG>?` with options `yes`, `no`, plus
-  one override option per package in the form `<name>: <level>` (e.g.
-  `myk-pi-tools: minor`) so the user can adjust any package's level
-  before confirming.
+  Phase 4 — the unmapped-changes display already happened in S2).
+  Otherwise: show the changelog, the per-package version
+  proposals (`current → proposed`), the plan's skipped-packages list,
+  AND any `unmapped_changes` files as text — the human validates the
+  detection on every scoped release (a package wrongly skipped is the
+  broken failure mode). Then a short `ask_user`: `Release?` with
+  options `yes`, `no`, plus one override option per package in the form
+  `<name>: <level>` (e.g. `myk-pi-tools: minor`) so the user can adjust
+  any package's level before confirming.
 - **Phase S5 — Bump:** `myk-pi-tools release bump-scoped --json` with
   one `--set <name>=<version>` per affected package carrying YOUR final
   proposed versions (after any user overrides). Use `--version X.Y.Z`
   instead when the user passed an explicit version. Parse the JSON:
-  stage ONLY the files in `updated[]`, use `tag` as the release version.
-  Bump PR, merge, and branch sync follow the standard Phase 5 delegation
-  (git-expert / github-expert), with the bump PR message
-  `chore: bump version to <TAG>`.
-- **Phase S6/S7:** unchanged — release create with `v<TAG>`, changelog
-  including the Shipped packages section, summary listing per-package
-  versions.
+  stage ONLY the files in `updated[]`; each entry in `packages[]`
+  carries its per-package `tag` (`<name>@<version>`). Bump PR, merge,
+  and branch sync follow the standard Phase 5 delegation (git-expert /
+  github-expert), with the bump PR message `chore: bump version to
+  <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. 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.
+  Summary lists each release URL and per-package versions.
 
 ### Phase 2: Version Detection