wendkeep 0.68.5 → 0.68.6

package/CHANGELOG.md

@@ -4,6 +4,15 @@ All notable changes to **wendkeep** are documented here. Format based on
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/); this project follows
 [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [0.68.6] — 2026-08-16
+
+### Fixed
+
+- **A orientação de atualização em monorepos pnpm agora resolve a versão publicada antes da
+  instalação.** README e guias bilíngues deixam de oferecer `X.Y.Z` como argumento copiável,
+  explicam o cooldown silencioso de `@latest` e orientam a regeneração segura do lock quando a
+  integridade do tarball divergir.
+
 ## [0.68.5] — 2026-08-14
 
 ### Fixed

package/README.en.md

@@ -176,24 +176,37 @@ The install stays outside `sync` on purpose: a running process cannot replace it
 keep going — the code in memory would still be the old one.
 
 In a **pnpm** monorepo the install command differs (`npm` in a pnpm repo fails with
-`Cannot read properties of null (reading 'matches')`) and the version must be **exact**:
-
-```bash
-pnpm add -D -w wendkeep@X.Y.Z --config.minimumReleaseAge=0 && npx --no-install wendkeep sync --project . --yes
+`Cannot read properties of null (reading 'matches')`). Resolve the published version first and
+reuse exactly the value returned:
+
+```powershell
+$version = pnpm view wendkeep version
+pnpm add -D -w "wendkeep@$version" --config.minimumReleaseAge=0
+pnpm install --update-checksums --config.minimumReleaseAge=0
+pnpm exec wendkeep sync --project . --yes
 ```
 
 > **Do not ask pnpm for `wendkeep@latest`.** pnpm 11 ignores packages published in the last
 > 24h by default (`minimumReleaseAge`, a supply-chain guard) — and it does not complain: it
 > installs the previous version, exits 0, and the only hint is a quiet `(X.Y.Z is available)`
 > in the output. You end up on the old version thinking you upgraded. Check with
-> `npx wendkeep --version`.
+> `pnpm exec wendkeep --version`.
+>
+> Do not edit only the version or integrity in `pnpm-lock.yaml`. `pnpm add` and
+> `pnpm install --update-checksums` must recalculate the complete entry. If the lock is already
+> inconsistent and `ERR_PNPM_TARBALL_INTEGRITY` appears, prune the local store and repeat:
+>
+> ```powershell
+> pnpm store prune
+> pnpm install --update-checksums --config.minimumReleaseAge=0
+> ```
 >
 > After installing, record the exception in `pnpm-workspace.yaml` — **pnpm does not write
 > that line for you**:
 >
 > ```yaml
 > minimumReleaseAgeExclude:
->   - wendkeep@X.Y.Z
+>   - wendkeep@<the version returned by pnpm view>
 > ```
 >
 > Without it, CI's `pnpm install` fails with `ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION` until

package/README.md

@@ -176,24 +176,37 @@ The install stays outside `sync` on purpose: a running process cannot replace it
 keep going — the code in memory would still be the old one.
 
 In a **pnpm** monorepo the install command differs (`npm` in a pnpm repo fails with
-`Cannot read properties of null (reading 'matches')`) and the version must be **exact**:
-
-```bash
-pnpm add -D -w wendkeep@X.Y.Z --config.minimumReleaseAge=0 && npx --no-install wendkeep sync --project . --yes
+`Cannot read properties of null (reading 'matches')`). Resolve the published version first and
+reuse exactly the value returned:
+
+```powershell
+$version = pnpm view wendkeep version
+pnpm add -D -w "wendkeep@$version" --config.minimumReleaseAge=0
+pnpm install --update-checksums --config.minimumReleaseAge=0
+pnpm exec wendkeep sync --project . --yes
 ```
 
 > **Do not ask pnpm for `wendkeep@latest`.** pnpm 11 ignores packages published in the last
 > 24h by default (`minimumReleaseAge`, a supply-chain guard) — and it does not complain: it
 > installs the previous version, exits 0, and the only hint is a quiet `(X.Y.Z is available)`
 > in the output. You end up on the old version thinking you upgraded. Check with
-> `npx wendkeep --version`.
+> `pnpm exec wendkeep --version`.
+>
+> Do not edit only the version or integrity in `pnpm-lock.yaml`. `pnpm add` and
+> `pnpm install --update-checksums` must recalculate the complete entry. If the lock is already
+> inconsistent and `ERR_PNPM_TARBALL_INTEGRITY` appears, prune the local store and repeat:
+>
+> ```powershell
+> pnpm store prune
+> pnpm install --update-checksums --config.minimumReleaseAge=0
+> ```
 >
 > After installing, record the exception in `pnpm-workspace.yaml` — **pnpm does not write
 > that line for you**:
 >
 > ```yaml
 > minimumReleaseAgeExclude:
->   - wendkeep@X.Y.Z
+>   - wendkeep@<the version returned by pnpm view>
 > ```
 >
 > Without it, CI's `pnpm install` fails with `ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION` until

package/docs/en/commands/getting-started.md

@@ -60,14 +60,22 @@ npm install --save-dev wendkeep@latest
 npx wendkeep sync --yes
 ```
 
-With pnpm, pin a concrete version because minimum-release-age policies may keep `latest` silently
-behind:
+With pnpm, query the published version and reuse the returned value. Minimum-release-age policies
+may keep `latest` silently behind; in a monorepo, `-w` targets the workspace root:
 
-```bash
-pnpm add -D wendkeep@X.Y.Z --config.minimumReleaseAge=0
+```powershell
+$version = pnpm view wendkeep version
+pnpm add -D -w "wendkeep@$version" --config.minimumReleaseAge=0
+pnpm install --update-checksums --config.minimumReleaseAge=0
 pnpm exec wendkeep sync --yes
 ```
 
+Do not edit only the version or integrity in `pnpm-lock.yaml`. If
+`ERR_PNPM_TARBALL_INTEGRITY` appears after a manual edit, run `pnpm store prune` and repeat
+`pnpm install --update-checksums --config.minimumReleaseAge=0`. The
+`minimumReleaseAgeExclude` entry in `pnpm-workspace.yaml` is also manual and must use the
+version returned by `pnpm view`; pnpm does not write that line.
+
 ## Expected result
 
 The project receives `.wendkeep.json`, managed Claude/Codex hooks, skill definitions, and an

package/docs/pt-BR/commands/getting-started.md

@@ -60,14 +60,22 @@ npm install --save-dev wendkeep@latest
 npx wendkeep sync --yes
 ```
 
-Com pnpm, informe uma versão concreta porque políticas de idade mínima podem manter `latest`
-atrasado silenciosamente:
+Com pnpm, consulte a versão publicada e reutilize o valor retornado. Políticas de idade mínima
+podem manter `latest` atrasado silenciosamente; em um monorepo, `-w` aponta para o workspace raiz:
 
-```bash
-pnpm add -D wendkeep@X.Y.Z --config.minimumReleaseAge=0
+```powershell
+$version = pnpm view wendkeep version
+pnpm add -D -w "wendkeep@$version" --config.minimumReleaseAge=0
+pnpm install --update-checksums --config.minimumReleaseAge=0
 pnpm exec wendkeep sync --yes
 ```
 
+Não edite apenas a versão ou a integridade no `pnpm-lock.yaml`. Se aparecer
+`ERR_PNPM_TARBALL_INTEGRITY` depois de uma edição manual, rode `pnpm store prune` e repita
+`pnpm install --update-checksums --config.minimumReleaseAge=0`. A exceção
+`minimumReleaseAgeExclude` do `pnpm-workspace.yaml` também é manual e deve usar a versão
+retornada por `pnpm view`; o pnpm não escreve essa linha.
+
 ## Resultado esperado
 
 O projeto recebe `.wendkeep.json`, hooks gerenciados de Claude/Codex, definições de skills e um

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "wendkeep",
-  "version": "0.68.5",
+  "version": "0.68.6",
   "description": "Vault-first persistent memory for AI coding agents, with an optional profile-aware governance runtime: OFF, FLOW, GUIDE, GOVERN, or ASSURE. Local-first and agent-agnostic (Claude Code, Codex, Cursor…).",
   "type": "module",
   "workspaces": [