jorgex-stack 1.8.0 → 1.8.1

package/README.md

@@ -97,7 +97,7 @@ Programmatic mode does **not** provide:
 
 ### Pi runtime
 
-Pi combines the frozen **snapshot v2** package with a Stack-owned shared projection. This adoption targets the exact published package **`jorgex-pi@0.6.1`** and keeps Pi out of the adapter/component manifest and model map. The Stack release that consumes it must pin `npm:jorgex-pi@0.6.1` in `src/lib/pi-runtime.ts`; this section does not claim that a user installation or `main` has already consumed it.
+Pi combines the frozen **snapshot v2** package with a Stack-owned shared projection. This adoption targets the exact published package **`jorgex-pi@0.7.0`** and keeps Pi out of the adapter/component manifest and model map. The Stack release that consumes it must pin `npm:jorgex-pi@0.7.0` in `src/lib/pi-runtime.ts`; this section does not claim that a user installation or `main` has already consumed it.
 
 ```bash
 pnpm dlx jorgex-stack install --agents pi
@@ -107,9 +107,9 @@ pnpm dlx jorgex-stack sync --agents pi
 pnpm dlx jorgex-stack uninstall --agents pi
 ```
 
-Stack downloads the frozen registry tarball, verifies its exact size plus SHA-256/SHA-512, backs up Pi's `settings.json`, and only then asks Pi to install that local file. For `0.6.1`, the frozen tarball is `89120966` bytes; the URL is derived from the version and the authoritative size/SHA-256/SHA-512 pin remains in `src/lib/pi-runtime.ts` rather than being duplicated here. Pi's own package-manager invocation is the narrow runtime exception to the repository's pnpm-only rule; the Stack lifecycle never launches npm directly. After the package is healthy, Stack projects the shared resources into Pi: marked `jorgex:system-prompt` and `jorgex:engram-protocol` sections in `~/.pi/agent/AGENTS.md`, canonical skills under `~/.agents/skills`, and `~/.pi/agent/prompts/lean-audit.md`. When the managed Playwright preference is active, the projection also adds or removes the marked `jorgex:browser` section dynamically. The Pi-only `install --agents pi --playwright` flow installs and persists that Playwright capability just like the other harnesses. Chrome DevTools MCP and Context7 remain outside the Pi scope. The managed Pi package entry is the exact object `{ "source": "npm:jorgex-pi@0.6.1", "skills": [], "prompts": [] }`; filters are applied only after this projection exists, so the package does not duplicate shared resources. Package ownership is recorded separately in `~/.jorgex-stack/pi-receipt.json`; projection ownership is recorded in `~/.jorgex-stack/pi-projection-receipt.json`. Both receipts are scope-bound and fail closed for manual, duplicate, divergent, partial, corrupt, copied-to-another-scope, or unknown-history state.
+Stack downloads the frozen registry tarball, verifies its exact size plus SHA-256/SHA-512, backs up Pi's `settings.json`, and only then asks Pi to install that local file. For `0.7.0`, the frozen tarball is `89125185` bytes; the URL is derived from the version and the authoritative size/SHA-256/SHA-512 pin remains in `src/lib/pi-runtime.ts` rather than being duplicated here. Pi's own package-manager invocation is the narrow runtime exception to the repository's pnpm-only rule; the Stack lifecycle never launches npm directly. After the package is healthy, Stack projects the shared resources into Pi: marked `jorgex:system-prompt` and `jorgex:engram-protocol` sections in `~/.pi/agent/AGENTS.md`, canonical skills under `~/.agents/skills`, and `~/.pi/agent/prompts/lean-audit.md`. When the managed Playwright preference is active, the projection also adds or removes the marked `jorgex:browser` section dynamically. The Pi-only `install --agents pi --playwright` flow installs and persists that Playwright capability just like the other harnesses. Chrome DevTools MCP and Context7 remain outside the Pi scope. The managed Pi package entry is the exact object `{ "source": "npm:jorgex-pi@0.7.0", "skills": [], "prompts": [] }`; filters are applied only after this projection exists, so the package does not duplicate shared resources. Package ownership is recorded separately in `~/.jorgex-stack/pi-receipt.json`; projection ownership is recorded in `~/.jorgex-stack/pi-projection-receipt.json`. Both receipts are scope-bound and fail closed for manual, duplicate, divergent, partial, corrupt, copied-to-another-scope, or unknown-history state.
 
-The published artifact has three separate provenance anchors: the release checkout and tarball producer is `fa3cc0dbf06398dc39f70fdf0ba99e4a10846203`; the SLSA workflow trigger/resolved-dependencies commit is `864c322d4c3ed8814cdd27092926451258d7e55d`; and the Stack parity source is `ebc55667ba610925227fcb575ae1f84750a53510`. Registry metadata has no `gitHead`. The npm attestation binds the exact tarball SHA-512 to the workflow and trigger `864c322d...`, not directly to `fa3cc0d...`; README therefore makes no claim that the attestation is a signature of the release checkout.
+The published artifact has three separate provenance anchors: the release checkout and tarball producer is `41b41b7a49617b59c7eb72bdedaa75455b362496`; the SLSA workflow run is `33481871250` on ref `main`, with resolved dependencies at the same commit `41b41b7...` (manual `0.7.0`, with no bump commit); and the Stack parity source is `1327d8dbe68e4118272a74a06c44a731bb346efa`. Registry metadata has no `gitHead`. The npm attestation binds the exact tarball SHA-512 to workflow run `33481871250`; README does not treat registry metadata as a separate source identity.
 
 Install, sync and uninstall back up every managed file before changing it and are idempotent. `doctor` reports package and projection drift without repairing it. Uninstall removes only receipt-owned package/projection state, retains shared files also owned by another runtime, and preserves user content outside marked sections. Engram remains user-owned and is never removed; the receipts only carry the verified executable hand-off required by the package.
 
@@ -117,7 +117,7 @@ The package owns Pi's native primary-model projection: `openai-codex/gpt-5.6-sol
 
 Engram remains mandatory and user-owned. An existing binary is preserved. Interactive install may offer the native `brew`/`go`/release channel with explicit confirmation; `--yes` and non-TTY installs fail with a remedy when Engram is absent. The database and memories are never updated or deleted, and uninstall never deletes the Engram binary. Under `--target-dir`, Stack accepts only `<target>/bin/engram`, isolates Pi/Home/XDG/AppData/temp/npm-cache paths inside the target, and never consults the host Engram or Pi configuration.
 
-The transition from `jorgex-pi@0.4.0` to `jorgex-pi@0.6.1` is not in-place. Each Stack release recognizes only the Pi receipt for its exact pin. The published Stack **`jorgex-stack@1.7.1`** is the corroborated release that recognizes `npm:jorgex-pi@0.4.0`; use it explicitly, never `latest`, to clean an old `0.4.0` receipt before installing the Stack release that pins `0.6.1`. Rollback is symmetric: first use the release that recognizes the present `0.6.1` receipt, then `jorgex-stack@1.7.1` if returning to `0.4.0`. Never edit receipts or hashes and never delete `HOME`, Engram, or another runtime's projection to force trust. The exact examples and failure behavior are in [docs/references/pi-runtime.md](docs/references/pi-runtime.md); the commands there are documentation, not commands executed by this adoption.
+The transition from `jorgex-pi@0.6.1` to `jorgex-pi@0.7.0` is not in-place. Each Stack release recognizes only the Pi receipt for its exact pin. The published Stack **`jorgex-stack@1.7.5`** is the corroborated release that recognizes `npm:jorgex-pi@0.6.1`; use it explicitly, never `latest`, to clean an old `0.6.1` receipt before installing `jorgex-stack@1.8.1`, which recognizes `0.7.0`. Rollback is symmetric: first use `jorgex-stack@1.8.1` to clean the present `0.7.0` receipt, then `jorgex-stack@1.7.5` to restore `0.6.1`. The earlier `0.4.0`/`jorgex-stack@1.7.1` pairing is historical context only, not part of this transition. Never edit receipts or hashes and never delete `HOME`, Engram, or another runtime's projection to force trust. The exact examples and failure behavior are in [docs/references/pi-runtime.md](docs/references/pi-runtime.md); the commands there are documentation, not commands executed by this adoption.
 
 The 24-hour npm maturity rule applies only to real managed installation or consumption of the new Pi package. Development, PR validation, merge and Stack publication may proceed immediately against the exact verified artifact; installing it on a real user scope before 24 hours requires Jorge's explicit exception.
 

package/dist/cli.js

@@ -5141,16 +5141,16 @@ import { createHash } from "crypto";
 var PI_RUNTIME_CANDIDATE = {
   package: {
     name: "jorgex-pi",
-    version: "0.6.1",
-    source: "npm:jorgex-pi@0.6.1"
+    version: "0.7.0",
+    source: "npm:jorgex-pi@0.7.0"
   },
   provenance: {
-    commit: "fa3cc0dbf06398dc39f70fdf0ba99e4a10846203"
+    commit: "41b41b7a49617b59c7eb72bdedaa75455b362496"
   },
   tarball: {
-    bytes: 89120966,
-    sha256: "9a4040ce34dba36aff56f618f957189749219f9560fb796e2b6864bdabf51b93",
-    sha512: "0b08a0ae2477c9dd0c2f62cbf15bc212d2ea9ef66c1a366e29c9f772ee73d073ab991d177583bbbaf3db8844053d7f34d8350a4acd9eb270c3887bd05cddd92f"
+    bytes: 89125185,
+    sha256: "4db392a68187a05a530e6d5ac4c45f834aab5972201edc9ef86da547981109e5",
+    sha512: "fb5fdcf15463f3dab36be9b2e6cb55b7397831fe8a172972666a0d6d146ba5e26e70b74e2962dc2702b4ae6ee025094291597c910f967dd924c5a51bd0cc655b"
   },
   pi: {
     testedVersions: ["0.84.2"]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jorgex-stack",
-  "version": "1.8.0",
+  "version": "1.8.1",
   "description": "Harness multi-agente portable: instala la config JorgeX (agentes, skills, hooks, Engram, MCPs) en Claude Code, Codex CLI, OpenCode y Pi",
   "type": "module",
   "license": "MIT",