cohorte 1.2.4 → 1.2.5

package/CHANGELOG.md

@@ -3,6 +3,15 @@
 Entries are shown by `/update-pipeline` ("What's new") after a core refresh. Keep them short,
 user-facing, most recent first. One `## <version> — <YYYY-MM-DD>` section per release.
 
+## 1.2.5 — 2026-07-29
+
+- **`.claude/pipeline.json`'s `core_version` never updated on global installs.** The installer
+  bumps it in bundled mode, but a global core is shared — it cannot know which repos point at
+  it, so nothing bumped the field and it drifted forever. Repos running a current core were
+  still claiming `1.0.0`. `/update-pipeline` now syncs the pointer in both modes.
+- `/doctor` no longer reports that drift as a broken install: a global-mode pointer lagging the
+  VERSION file is ⚠️ with the one-command fix, not ❌. The core was never the problem.
+
 ## 1.2.4 — 2026-07-29
 
 > **If you installed with `npx cohorte`, this is the release that makes 1.2.3 actually

package/core/commands/doctor.md

@@ -14,8 +14,10 @@ fix only with the human's go-ahead (or hand them the command).
 
 1. **Core & pointer.** A core exists (`~/.claude/pipeline/VERSION` global, and/or
    `.claude/pipeline/VERSION` bundled); `.claude/pipeline.json` names a mode + `core_version`
-   coherent with the VERSION file. Compare against `npm view cohorte version` — behind ⇒
-   suggest `/update-pipeline`. Read `pipeline/CHANGELOG.md` for what they're missing. The router
+   coherent with the VERSION file. A **global**-mode pointer lagging the VERSION file is ⚠️, not ❌:
+   nothing bumped that field before 1.2.5, so the core itself is fine and only the pointer is stale
+   ⇒ fix by running `/update-pipeline` (§3 syncs it now), or by editing the one field. Compare
+   against `npm view cohorte version` — behind ⇒ suggest `/update-pipeline`. Read `pipeline/CHANGELOG.md` for what they're missing. The router
    commands' step files are present — `templates/steps/init-pipeline/` non-empty (a router whose
    `templates/steps/<cmd>/` dir is missing is a partial/stale install ⇒
    re-run install/update). **Shipped scripts present and executable** in `<core>/pipeline/scripts/`:

package/core/commands/update-pipeline.md

@@ -51,7 +51,14 @@ the human's choices — so `/init-pipeline` never needs re-running for an upgrad
 ## 3. Report old → new
 
 Re-read the VERSION file(s) and print `old → new`. If unchanged, say the core was already up to date.
-For a bundled repo, note that `.claude/pipeline.json`'s `core_version` was bumped and should be committed.
+
+**Sync the pointer — in BOTH modes.** If this repo has a `.claude/pipeline.json` whose `core_version`
+differs from the core you just installed, rewrite that one field (leave every other field untouched)
+and tell the human to commit it. In **bundled** mode the installer already did it; in **global** mode
+**nothing does** — the installer refreshes one shared core and cannot know which repos point at it,
+so before 1.2.5 the field simply drifted forever (a repo on a current core still claiming `1.0.0`).
+`/doctor` check 1 requires the pointer to be coherent with the VERSION file, so a drifted field reads
+as a broken install when nothing is broken.
 
 Then print **What's new**: read the installed `<core>/pipeline/CHANGELOG.md` and show the entries
 between the old and new versions (most recent first). File absent ⇒ the old core predates 0.1.14 —

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cohorte",
-  "version": "1.2.4",
+  "version": "1.2.5",
   "description": "Portable, stack-agnostic multi-agent development pipeline for Claude Code — install the core, run /init-pipeline, and it adapts to your project's stack.",
   "bin": {
     "cohorte": "bin/cli.js"