jorgex-stack 1.9.71 → 1.9.73

package/README.md

@@ -35,11 +35,8 @@ The skill never edits artifacts or creates tasks. During audit remediation, the
 Install and run via npm without cloning the repository:
 
 ```bash
-# First installation
+# Install (also reapplies mode, models, permissions and browser guidance to the configured runtimes).
 pnpm dlx jorgex-stack install
-
-# Already installed: apply the latest published stack while keeping the existing model selection
-pnpm dlx jorgex-stack sync
 ```
 
 For a fresh Engram installation, always consult the current published Stack and bypass only the `pnpm dlx` cache:
@@ -70,7 +67,7 @@ Runtime defaults are documented in [docs/references/permissions.md](docs/referen
 
 ### Modes: Human and Programmatic
 
-`install` and `sync` accept two mutually-exclusive installation modes. The choice is global (not per runtime) and is saved in `~/.jorgex-stack/install-mode.json` on first run; subsequent `sync` calls reuse it. Re-run `install` with `--mode` to switch.
+`install` accepts two mutually-exclusive installation modes. The choice is global (not per runtime) and is saved in `~/.jorgex-stack/install-mode.json` on first run; subsequent `install` calls reuse it. Re-run `install` with `--mode` to switch.
 
 | Mode | Audience | Final assistant response | Subagents |
 |------|----------|--------------------------|-----------|
@@ -98,7 +95,7 @@ Flags:
 
 - `--mode human` cannot be combined with `--subagent-concurrency`.
 - Without `--mode`, the first run asks interactively; `--yes`, non-TTY, and `--target-dir` default to `human`.
-- `pnpm dlx jorgex-stack sync` reuses the saved mode; pass `--mode` to change and save the preference.
+- `pnpm dlx jorgex-stack install` reuses the saved mode; pass `--mode` to change and save the preference.
 
 Programmatic mode guarantees:
 
@@ -118,7 +115,7 @@ El canon de Stack y el paquete Pi mantienen una snapshot de 17 árboles de skill
 
 Pi combines the **snapshot v2** package with a Stack-owned shared projection. Package resolution, verification, receipt and recovery behavior are documented in [docs/references/pi-runtime.md](docs/references/pi-runtime.md); historical pins are not a promise that personal Pi installations have migrated.
 
-En Pi nuevo, Stack gestiona `jorgex-pi` y sus seis companions locales, y prepara el provider oficial `gentle-engram` en un stage aislado. Cuando el candidato Pi verificado declara el contrato nativo `mcp-native-v1`, `install` o `update` deliberado ejecuta la fase nativa (`runNativePiMcpPhase`) antes de la promoción del paquete: `mcp.json` pasa a ser la autoridad persistente de los servidores protegidos (`engram`, `context7`, `chrome-devtools`), no se instala `pi-mcp-adapter` y la autoridad granular vive en `pi-projection-receipt.json`. La fase nativa solo **prepara** (`NativeMcpPreparedWrite` con `created`/`removals`/`snapshot`/`backupRoot`); el handoff activo y `mcp.json` los escribe el ciclo de proyección (`runPiProjectionLifecycleSystem`), que aplica el handoff DevTools v3 contra la estampa `receipt.devtools.sha256` y, después del readback, invoca una sola vez `pendingNativeConfigWrite` (CAS de remociones y crements con `restoreOwnedWrite`); sólo entonces publica el receipt y la autoridad final. Cada `install` o `update` deliberado resuelve el `latest` publicado, verifica lock/SRI/árbol y promociona solo el provider gentle en modo nativo (o los dos providers en modo legacy); conserva el enlace y receipt privados de `jorgex-pi`, el host Pi, las entradas npm ajenas y los datos de Engram. Con un receipt Stack válido, `install --agents pi` continúa por la actualización autenticada; el estado manual o ambiguo se bloquea. El [inventario de Pi](docs/references/pi-runtime.md#inventario-operativo-de-pi) distingue componentes obligatorios y opcionales, y la sección de [transporte nativo y autoridad granular](docs/references/pi-runtime.md#transporte-nativo-y-autoridad-granular) describe el contrato nativo verificable (no se infiere por versión del host ni por `testedVersions`); el opt-out explícito de DevTools retira el claim de la autoridad y, cuando la entrada sigue full-stamped, el `mcp.json` la elimina; cuando está personalizada la conserva y queda UNOWNED (no se reclama de vuelta por SHA idéntico y exige resolución manual).
+En Pi nuevo, Stack gestiona `jorgex-pi` y sus seis companions locales, y prepara el provider oficial `gentle-engram` en un stage aislado. Cuando el candidato Pi verificado declara el contrato nativo `mcp-native-v1`, `install` o `update` deliberado ejecuta la fase nativa (`runNativePiMcpPhase`) antes de la promoción del paquete: `mcp.json` pasa a ser la autoridad persistente de los servidores protegidos (`engram`, `context7`, `chrome-devtools`), no se instala `pi-mcp-adapter` y la autoridad granular vive en `pi-projection-receipt.json`. La fase nativa solo **prepara** (`NativeMcpPreparedWrite` con `created`/`removals`/`snapshot`/`backupRoot`); el handoff activo y `mcp.json` los escribe el ciclo de proyección (`runPiProjectionLifecycleSystem`), que aplica el handoff DevTools v3 contra la estampa `receipt.devtools.sha256` y, después del readback, invoca una sola vez `pendingNativeConfigWrite` (CAS de remociones y creaciones con `restoreOwnedWrite`); sólo entonces publica el receipt y la autoridad final. Cada `install` o `update` deliberado resuelve el `latest` publicado, verifica lock/SRI/árbol y promociona solo el provider gentle en modo nativo (o los dos providers en modo legacy); conserva el enlace y receipt privados de `jorgex-pi`, el host Pi, las entradas npm ajenas y los datos de Engram. Con un receipt Stack válido, `install --agents pi` continúa por la actualización autenticada; el estado manual o ambiguo se bloquea. El [inventario de Pi](docs/references/pi-runtime.md#inventario-operativo-de-pi) distingue componentes obligatorios y opcionales, y la sección de [transporte nativo y autoridad granular](docs/references/pi-runtime.md#transporte-nativo-y-autoridad-granular) describe el contrato nativo verificable (no se infiere por versión del host ni por `testedVersions`); el opt-out explícito de DevTools retira el claim de la autoridad y, cuando la entrada sigue full-stamped, el `mcp.json` la elimina; cuando está personalizada la conserva y queda UNOWNED (no se reclama de vuelta por SHA idéntico y exige resolución manual).
 
 The following command block is retained as historical reference for that transition:
 
@@ -130,7 +127,7 @@ pnpm dlx jorgex-stack@1.9.7 sync --agents pi
 pnpm dlx jorgex-stack@1.9.7 uninstall --agents pi
 ```
 
-For a deliberate managed install or update, Stack resolves the live published `latest` tag to an exact release, verifies its canonical tarball URL and SRI/bytes, and prepares it in an isolated stage before activation. The stage locks six direct dependencies, copies them byte-identically into the package-local runtime tree, and records those copies only in the tree inventory; the lock remains the verified lock, and the release id uses both lock and tree digests; it then runs the RPC smoke before and after promotion. Stack then backs up state and publishes only its owned package entry. Automatic restoration covers activation/verification failures; if projection or MCP configuration fails after the package is activated and verified, Stack blocks with the backup retained rather than claiming a full rollback. The schema 1 receipt records managed-package evidence for offline verification. `sync`, `models`, `doctor` and `uninstall` do not acquire a new version; they require an authenticated receipt/artifact, with explicit legacy recovery paths where applicable. `update --check` does not download. `--target-dir` neither downloads Pi nor touches the real HOME; with a previously verified candidate/stage injected, it can run isolated smoke/runner code inside the target. Direct Pi installation is separate and does not provide Stack's rollback guarantees. Do not use Pi's native `pi update --extensions` as a Stack repair path: it does not provide the managed receipt or Stack's activation/recovery guarantees. A Pi release is adopted only after its reader declaration, tarball and integrity pass the verified stage; no future version is pinned manually.
+For a deliberate managed install or update, Stack resolves the live published `latest` tag to an exact release, verifies its canonical tarball URL and SRI/bytes, and prepares it in an isolated stage before activation. The stage locks six direct dependencies, copies them byte-identically into the package-local runtime tree, and records those copies only in the tree inventory; the lock remains the verified lock, and the release id uses both lock and tree digests; it then runs the RPC smoke before and after promotion. Stack then backs up state and publishes only its owned package entry. Automatic restoration covers activation/verification failures; if projection or MCP configuration fails after the package is activated and verified, Stack blocks with the backup retained rather than claiming a full rollback. The schema 1 receipt records managed-package evidence for offline verification. `models`, `doctor` and `uninstall` do not acquire a new version; they require an authenticated receipt/artifact, with explicit legacy recovery paths where applicable. Deliberate `install`/`update` can resolve and download Pi and its providers; browser acquisition requires explicit opt-in or a persisted preference. `update --check` does not download. `--target-dir` neither downloads Pi nor touches the real HOME; with a previously verified candidate/stage injected, it can run isolated smoke/runner code inside the target. Direct Pi installation is separate and does not provide Stack's rollback guarantees. Do not use Pi's native `pi update --extensions` as a Stack repair path: it does not provide the managed receipt or Stack's activation/recovery guarantees. A Pi release is adopted only after its reader declaration, tarball and integrity pass the verified stage; no future version is pinned manually.
 
 The artifact values in `src/lib/pi-runtime-pin.json` describe frozen historical/reference metadata, not the live install candidate; live artifact URL, version and integrity are resolved from the published registry.
 
@@ -146,37 +143,37 @@ The historical published artifact has two separate provenance anchors. The local
 
 The historical `0.8.0` artifact records two distinct commit identities: the release checkout and tarball producer is `9f999747df3e335947a61d38e581555367973b09` (`main`, release `0.8.0`); and the Stack parity source is `11e7666ea4e40bde1de8bc434610747eb797ab9c`. Registry metadata has no `gitHead`; README does not invent a separate source identity, attestation or signature.
 
-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.
+Install 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.
 
 The package owns Pi's native primary-model projection: `openai-codex/gpt-5.6-sol`, with a local `contextWindow` request of 872K. It merges only missing compatible fields, records field ownership in `PI_CODING_AGENT_DIR/jorgex-pi/sol-lifecycle.v1.json`, and cleanup removes only still-owned canonical values. Stack does not duplicate that package-owned settings/models logic. The 872K value is local OAuth metadata until a real long-context smoke test confirms backend acceptance; it is not the API context limit.
 
-Engram remains mandatory and user-owned. An existing binary is always preserved. When it is missing and the user authorizes installation, Stack resolves GitHub's current official latest stable release at runtime; GitHub's `releases/latest` endpoint excludes prereleases and drafts, and the installer never uses a branch. It matches the exact platform/architecture asset and validates its live metadata —published state, expected name, positive size and SHA-256— before publishing; missing network or metadata fails closed, with no static or offline fallback. Use `--engram` to authorize that download in non-interactive flows. The release installer writes only `~/.local/bin/engram` (or the platform equivalent) and does not use Brew or Go. `sync`, dry-run and `--target-dir` never download it. Update remains explicit and does not replace an existing binary implicitly. The database and memories are never updated or deleted, and uninstall preserves the official Engram artifacts and never removes 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. This rolling channel does not mean that every upstream release was pre-reviewed by Stack.
+Engram remains mandatory and user-owned. An existing binary is always preserved. When it is missing and the user authorizes installation, Stack resolves GitHub's current official latest stable release at runtime; GitHub's `releases/latest` endpoint excludes prereleases and drafts, and the installer never uses a branch. It matches the exact platform/architecture asset and validates its live metadata —published state, expected name, positive size and SHA-256— before publishing; missing network or metadata fails closed, with no static or offline fallback. `install` may download Engram with `--engram` or with interactive confirmation; `update` only offers the explicit native channel confirmation and preserves the existing binary. The release installer writes only `~/.local/bin/engram` (or the platform equivalent) and does not use Brew or Go. El `sync` interno, `dry-run` y `--target-dir` no descargan Engram. Update permanece explícito y no sustituye un binario existente implícitamente. The database and memories are never updated or deleted, and uninstall preserves the official Engram artifacts and never removes 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. This rolling channel does not mean that every upstream release was pre-reviewed by Stack.
 
 Claude's official plugin still requires stable Engram 2.0.0 or newer: an existing binary below that minimum would make its setup write the obsolete `mcp/engram.json`, so the Claude preflight blocks it before setup. Stack never replaces an existing binary automatically; update it explicitly and rerun `install`. The official Claude plugin contributes hooks and its skill; `engram setup claude-code` registers a separate user-scoped MCP, not a bundled MCP. This integration does not claim an authenticated model-tool smoke.
 
 ### Integración oficial de Engram
 
-En una instalación real, `install` delega Claude Code, Codex y OpenCode 1.x a `engram setup <runtime>` una vez por runtime durante esa instalación. Para Pi, si declara transporte nativo (`mcp-native-v1`), Stack ejecuta la fase nativa (`runNativePiMcpPhase`) y no invoca `engram setup pi`; en modo legacy Pi sigue ejecutando `engram setup pi` antes de activar el paquete. El comportamiento del provider oficial permanece sin cambios: Stack no proyecta el protocolo Engram ni filtra sus herramientas. No ejecuta ese setup durante `sync`, `dry-run`, `--target-dir`, `doctor` ni `uninstall`. Stack respalda los archivos afectados, verifica los artefactos oficiales y revierte el cambio si falla; para Pi incluye `settings.json`, `mcp.json` y el árbol `npm`. No modifica `~/.engram`, sus memorias ni reemplaza un binario existente. Los artefactos oficiales se conservan al desinstalar. El `stack/plugins/opencode/engram.ts` legado ya no se despliega y queda retirado por esta integración.
+En una instalación real, `install` delega Claude Code, Codex y OpenCode 1.x a `engram setup <runtime>` una vez por runtime durante esa instalación. Para Pi, si declara transporte nativo (`mcp-native-v1`), Stack ejecuta la fase nativa (`runNativePiMcpPhase`) y no invoca `engram setup pi`; en modo legacy Pi sigue ejecutando `engram setup pi` antes de activar el paquete. El comportamiento del provider oficial permanece sin cambios: Stack no proyecta el protocolo Engram ni filtra sus herramientas. No ejecuta ese setup durante `dry-run`, `--target-dir`, `doctor` ni `uninstall`; `install` lo invoca como parte de la reconciliación interna cuando es necesario. Stack respalda los archivos afectados, verifica los artefactos oficiales y revierte el cambio si falla; para Pi incluye `settings.json`, `mcp.json` y el árbol `npm`. No modifica `~/.engram`, sus memorias ni reemplaza un binario existente. Los artefactos oficiales se conservan al desinstalar. El `stack/plugins/opencode/engram.ts` legado ya no se despliega y queda retirado por esta integración.
 
-Para Codex, Engram 2.0 ignora `CODEX_HOME` y escribe siempre en `$HOME/.codex`; por eso el setup oficial real requiere ese destino predeterminado. Si `CODEX_HOME` apunta a otro directorio, `install` falla cerrado en el preflight, antes de escribir la configuración de Codex, y recomienda usar `$HOME/.codex`. `sync`, `dry-run` y `--target-dir` no invocan el setup oficial.
+Para Codex, Engram 2.0 ignora `CODEX_HOME` y escribe siempre en `$HOME/.codex`; por eso el setup oficial real requiere ese destino predeterminado. Si `CODEX_HOME` apunta a otro directorio, `install` falla cerrado en el preflight, antes de escribir la configuración de Codex, y recomienda usar `$HOME/.codex`. `dry-run` y `--target-dir` no invocan el setup oficial.
 
-La política de complementos distingue estrategias `exact` y `provider-managed`. DevTools MCP y Playwright CLI son `provider-managed`: un `install`/`update` deliberado resuelve y verifica el candidato exacto antes de activarlo, y guarda versión/integridad observadas para reconciliar sin consultar al proveedor en `sync`. Las integraciones oficiales de Engram también son `provider-managed`/rolling, incluido Codex `main`, `pi-mcp-adapter` y el setup oficial de Pi sin pin en Stack. OpenCode 2 queda fuera de alcance y no bloquea esta integración.
+La política de complementos distingue estrategias `exact` y `provider-managed`. DevTools MCP y Playwright CLI son `provider-managed`: un `install`/`update` deliberado resuelve y verifica el candidato exacto antes de activarlo, y guarda versión/integridad observadas para que `install`/`update` posteriores refresquen usando la preferencia persistida o el opt-in explícito. Las integraciones oficiales de Engram también son `provider-managed`/rolling, incluido Codex `main`, `pi-mcp-adapter` y el setup oficial de Pi sin pin en Stack. OpenCode 2 queda fuera de alcance y no bloquea esta integración.
 
 Los receipts históricos, incluido `jorgex-pi@0.8.24`, son evidencia para recuperación/migración y no candidatos de instalación nuevos. La selección gestionada resuelve el `latest` publicado a una versión exacta y verifica el artefacto antes de activarlo. No edites receipts o hashes ni borres `HOME`, Engram o la proyección de otro runtime para forzar confianza. La migración y rollback están en [docs/references/pi-runtime.md](docs/references/pi-runtime.md).
 
 Stack gestiona la selección dinámica y verificación de Pi en `install`/`update`; esto no significa que una instalación personal de Pi se haya migrado. La automatización Stack ↔ Pi es snapshot-only. La instalación directa de Pi no incluye la etapa aislada ni el rollback de Stack.
 
-`update --agents pi` cambia versiones deliberadamente: resuelve y verifica el paquete Pi y los providers oficiales en stages aislados (con candidato nativo solo `gentle-engram`; con candidato legacy también `pi-mcp-adapter`), aplica la promoción acotada y verifica la configuración MCP. No entra en el updater global de Stack, no actualiza el host Pi ni toca los datos de Engram. `sync --agents pi` reaplica la proyección a partir del paquete autenticado y comprueba el estado MCP existente; no resuelve versiones ni descarga providers. `update --check --agents pi` consulta el runner sin mutar Pi; `doctor --agents pi` diagnostica paquete y proyección. Uninstall respalda los settings y retira solo el paquete exacto acreditado por el receipt, verificando su ausencia y conservando companions y estado ajeno. En modo nativo, `uninstall` corre la comprobación activa de ownership contra el módulo Pi realmente instalado antes de desactivar el paquete privado y respeta la autoridad granular `mcpNative` para decidir qué entradas retira. Consulta los límites de recuperación en la [referencia Pi](docs/references/pi-runtime.md).
+`update --agents pi` cambia versiones deliberadamente: resuelve y verifica el paquete Pi y los providers oficiales en stages aislados (con candidato nativo solo `gentle-engram`; con candidato legacy también `pi-mcp-adapter`), aplica la promoción acotada y verifica la configuración MCP. No entra en el updater global de Stack, no actualiza el host Pi ni toca los datos de Engram. `install --agents pi` reaplica la proyección a partir del paquete autenticado y comprueba el estado MCP existente cuando ya hay receipt; en primera instalación verifica el tarball, normaliza el paquete, proyecta recursos y ejecuta el sync interno para inicializar Pi y escribir ambos receipts. `update --check --agents pi` consulta el runner sin mutar Pi; `doctor --agents pi` diagnostica paquete y proyección. Uninstall respalda los settings y retira solo el paquete exacto acreditado por el receipt, verificando su ausencia y conservando companions y estado ajeno. En modo nativo, `uninstall` corre la comprobación activa de ownership contra el módulo Pi realmente instalado antes de desactivar el paquete privado y respeta la autoridad granular `mcpNative` para decidir qué entradas retira. Consulta los límites de recuperación en la [referencia Pi](docs/references/pi-runtime.md).
 
-### Variante temporal del provider y recibo separado (candidato, devtool)
+### Compat del provider #1567 (publicada en 1.9.69) y recibo separado
 
-> **Candidato / devtool — todavía no publicado en npm.** Mientras la corrección upstream `#1567` de `gentle-engram` no se publique, `--engram-typebox-compat` extiende la fase nativa del padre (PR203), ya importada como base, bajo la misma política de input/receipt de la flag candidata verificada y sin duplicar authority, config ni cardinality nativos. El caller nativo del padre (`runNativePiMcpPhase` y sus receipts análogos) no se reutiliza aquí como updater; el candidato no lo sustituye. Esta sección no declara Windows, MCP nativo, autorización personal, instalación nativa fresca, publicación ni aplicación personal como verificadas. La variante descrita es un artefacto local derivado —no es un fork ni un release npm— que aplica sólo el diff de `#1567` sobre bytes oficiales verificados, registra su procedencia en un recibo separado y se retira cuando el release oficial corregido se active como `registry`.
+> **Compat del provider #1567 publicada en Stack 1.9.69.** `--engram-typebox-compat` aplica el diff de `#1567` sobre bytes oficiales verificados y registra su procedencia en un recibo separado, sin sustituir la autoridad de la fase nativa. Los gates CI Windows controlados del release están verdes; la instalación personal en Windows no está probada. Cuando el provider oficial ya viene corregido, se usa sin etapa derivada.
 
-`--engram-typebox-compat` es un booleano explícito; cuando no se pasa, la propiedad queda **realmente ausente** (`undefined`) y no se conserva ninguna preferencia ni se añaden campos obligatorios a flags/fixtures. Sólo se acepta en `install` y `update` deliberados cuyo `--agents` incluya `pi` y **sin** combinar con `--dry-run` ni `--target-dir`; `update --check`, `--dry-run` y `--target-dir` (en `install` o `update`), `sync`, `models`, `doctor`, `uninstall` e `install` sin `pi` rechazan el flag antes de cualquier efecto. `--dry-run` y `--target-dir` siguen sin adquirir providers ni escribir estado personal. Stack registra la procedencia de `gentle-engram` y `pi-mcp-adapter` en `<home>/.jorgex-stack/pi-provider-receipt.json` (schemaVersion 1), un archivo distinto del `pi-receipt.json` del paquete JorgeX Pi y de la autoridad MCP. El campo `provenance` es **opcional** ligado a la adquisición `#1567`-compat: cuando el oficial ya viene corregido el builder devuelve `provenance.origin = "registry"`; mientras no, devuelve `provenance.origin = "derived"`; en ambos casos se descarta el `path` de stage y se conserva el payload original del manifiesto como `manifestBase64` (texto base64 que decodifica al manifiesto bounded —el límite aplica al payload decodificado, no al string literal) junto con su digest y la referencia del patch para verificación offline. Es procedencia local reproducible, no attestation independiente del publisher. `doctor` lee este recibo y diferencia `registry` vs `derived`; no consulta la red, no repara y nunca presenta un error como setup sano. Una `update` deliberada sobre derivado existente conserva la receta sin volver a requerir el flag, sólo si el recibo verificado lo permite; no se autosiembran preferencias y ningún otro comando propaga el opt-in. Las garantías de transacción (backup, idempotencia, rollback, detección de modificaciones ajenas con reporte de `recovery incomplete`), la retirada tras activación verificada del oficial corregido y la advertencia de que operaciones fuera de la transacción gestionada de Stack (comandos manuales, removedores externos, updater nativo de Pi en modo manual) pueden sustituir o degradar los bytes del provider —y que el verificador detecta ese drift sin ser una ACL— se describen en [la referencia Pi](docs/references/pi-runtime.md#variante-temporal-del-provider-y-recibo-separado-candidato-devtool). El updater de providers de **Stack** (función) opera sólo sobre el **transporte legacy**; el transporte nativo lo maneja la **fase nativa del padre** (PR203, `runNativePiMcpPhase`) con la misma política de opt-in y snapshot, sin duplicar la autoridad nativa. Un recibo nativo aún no publicado no debe presentarse como instalación nativa sana; este candidato no declara Windows, cohorte público, publicación npm ni aplicación personal como verificados. La autoridad MCP nativo, el set nativo y la cardinalidad de la cohorte pública pertenecen a PR203; este contrato no los duplica ni los anticipa.
+`--engram-typebox-compat` es un booleano explícito; cuando no se pasa, la propiedad queda **realmente ausente** (`undefined`) y no se conserva ninguna preferencia ni se añaden campos obligatorios a flags/fixtures. Sólo se acepta en `install` y `update` deliberados cuyo `--agents` incluya `pi` y **sin** combinar con `--dry-run` ni `--target-dir`; `update --check`, `--dry-run` y `--target-dir` (en `install` o `update`), `models`, `doctor`, `uninstall` e `install` sin `pi` rechazan el flag antes de cualquier efecto. `--dry-run` y `--target-dir` siguen sin adquirir providers ni escribir estado personal. Stack registra la procedencia de `gentle-engram` y `pi-mcp-adapter` en `<home>/.jorgex-stack/pi-provider-receipt.json` (schemaVersion 1), un archivo distinto del `pi-receipt.json` del paquete JorgeX Pi y de la autoridad MCP. El campo `provenance` es **opcional** ligado a la adquisición `#1567`-compat: cuando el oficial ya viene corregido el builder devuelve `provenance.origin = "registry"`; mientras no, devuelve `provenance.origin = "derived"`; en ambos casos se descarta el `path` de stage y se conserva el payload original del manifiesto como `manifestBase64` (texto base64 que decodifica al manifiesto bounded —el límite aplica al payload decodificado, no al string literal) junto con su digest y la referencia del patch para verificación offline. Es procedencia local reproducible, no attestation independiente del publisher. `doctor` lee este recibo y diferencia `registry` vs `derived`; no consulta la red, no repara y nunca presenta un error como setup sano. Una `update` deliberada sobre derivado existente conserva la receta sin volver a requerir el flag, sólo si el recibo verificado lo permite; no se autosiembran preferencias y ningún otro comando propaga el opt-in. Las garantías de transacción (backup, idempotencia, rollback, detección de modificaciones ajenas con reporte de `recovery incomplete`), la retirada tras activación verificada del oficial corregido y la advertencia de que operaciones fuera de la transacción gestionada de Stack (comandos manuales, removedores externos, updater nativo de Pi en modo manual) pueden sustituir o degradar los bytes del provider —y que el verificador detecta ese drift sin ser una ACL— se describen en [la referencia Pi](docs/references/pi-runtime.md#variante-temporal-del-provider-y-recibo-separado-candidato-devtool). El updater de providers de **Stack** (función) opera sólo sobre el **transporte legacy**; el transporte nativo lo maneja la **fase nativa del padre** (PR203, `runNativePiMcpPhase`) con la misma política de opt-in y snapshot, sin duplicar la autoridad nativa.
 
 ### Estilo global de escritura
 
-Stack incluye un prompt genérico de estilo de escritura como parte de su canon. `install` y `sync` lo gestionan en `~/.jorgex-stack/writing-style.md`; en modo humano proyectan el contenido efectivo directamente en una sección independiente de las instrucciones globales de los runtimes seleccionados. El prompt se aplica a la prosa dirigida al usuario, sigue el idioma en el que escribe el usuario salvo que pida otro y conserva las instrucciones técnicas, los formatos de máquina, el código y la configuración nativa. El modo programático conserva la fuente local, pero omite la proyección de prosa.
+Stack incluye un prompt genérico de estilo de escritura como parte de su canon. `install` lo gestiona en `~/.jorgex-stack/writing-style.md`; en modo humano proyecta el contenido efectivo directamente en una sección independiente de las instrucciones globales de los runtimes seleccionados. `install`/`update` reconcilian el canon internamente sin exponer un comando público de sync. El prompt se aplica a la prosa dirigida al usuario, sigue el idioma en el que escribe el usuario salvo que pida otro y conserva las instrucciones técnicas, los formatos de máquina, el código y la configuración nativa. El modo programático conserva la fuente local, pero omite la proyección de prosa.
 
 La proyección contiene el canon directamente: Stack no añade un wrapper adicional ni una identidad personal. Si falta el archivo local o está vacío, Stack recrea el bloque gestionado. El corpus de mensajes y los informes privados de análisis no se distribuyen en el paquete. Consulta [configuración, prueba aislada, diagnóstico y límites](docs/references/writing-style.md).
 
@@ -203,7 +200,7 @@ jorgex-stack browser playwright -s=mi-tarea close
 pnpm dlx jorgex-stack install --devtools
 ```
 
-`sync` revalida el receipt local sin resolver ni descargar paquetes browser y retira la guía si el estado gestionado falla. `doctor` revisa receipt, versión, caché Chromium y arranque headless local sin reparar. `update --check` observa solo estado local; `install` o `update` interactivo deliberados pueden adquirir un nuevo release verificado. `uninstall` conserva por defecto el árbol gestionado y los datos del navegador; `--remove-playwright` desactiva preferencia y guía con backup, sin retirar un CLI global ajeno. Una preferencia ilegible bloquea mutaciones y `doctor` señala su ruta. Con `--target-dir` Stack no toca el estado browser del HOME real. Consulta [automatización de navegador](docs/references/browser-automation.md) para receipts, reparación y handoffs Pi.
+`install`/`update` pueden adquirir un nuevo release browser verificado con opt-in explícito o preferencia persistida; no son una alternativa offline al comando retirado `sync`. `doctor` revisa receipt, versión, caché Chromium y arranque headless local sin reparar. `update --check` observa solo estado local. `uninstall` conserva por defecto el árbol gestionado y los datos del navegador; `--remove-playwright` desactiva preferencia y guía con backup, sin retirar un CLI global ajeno. Una preferencia ilegible bloquea mutaciones y `doctor` señala su ruta. Con `--target-dir` Stack no toca el estado browser del HOME real. Consulta [automatización de navegador](docs/references/browser-automation.md) para receipts, reparación y handoffs Pi.
 
 ### Update: Interactive Flow
 
@@ -225,7 +222,7 @@ GitHub authentication: requests use `GH_TOKEN`/`GITHUB_TOKEN` from the environme
 
 Goal Mode de OpenCode se ha retirado. Stack ya no instala su plugin ni el comando `/goal`; la continuidad de trabajo usa el lifecycle normal: `work/{name}/PRD.md` y `plan.md` permanecen durante los merges intermedios, `work/{name}/pr/{NN}` conserva cada checkpoint y `work/{name}/done` queda reservado para el cierre final.
 
-La retirada no migra el historial. `sync` sólo puede retirar archivos gestionados cuando dispone de un manifest legible que registre esas rutas como gestionadas y un inventario completo, con backup previo; conserva los datos existentes en `~/.jorgex-stack/goals` y los plugins ajenos cuando el manifest del Stack está íntegro. El registro local no autentica la propiedad ni corrige una lista `owned` editada o inconsistente: si falta, no se puede parsear o el inventario es incompleto, no se borra el legacy. Ante sospecha sobre el manifest, no ejecutes `sync`; revísalo o restáuralo con backup. `--target-dir` no implica limpiar ese estado.
+La retirada no migra el historial. `install`/`update` sólo retiran archivos gestionados cuando disponen de un manifest legible que registre esas rutas como gestionadas y un inventario completo, con backup previo; conservan los datos existentes en `~/.jorgex-stack/goals` y los plugins ajenos cuando el manifest del Stack está íntegro. El registro local no autentica la propiedad ni corrige una lista `owned` editada o inconsistente: si falta, no se puede parsear o el inventario es incompleto, no se borra el legacy. Ante sospecha sobre el manifest, no ejecutes `install`/`update`; revísalo o restáuralo con backup. `--target-dir` no implica limpiar ese estado.
 
 La continuidad entre checkpoints sigue requiriendo trabajo aprobado, capacidades disponibles y merge humano explícito. PiGoal conserva su propio lifecycle. No se afirma disponibilidad de una alternativa GoalV2 de OpenCode.
 

package/dist/cli.d.ts

@@ -7,7 +7,7 @@
 type RuntimeId = "claude-code" | "codex" | "opencode";
 type SelectableRuntimeId = RuntimeId | "pi";
 
-declare const COMMANDS: readonly ["install", "sync", "models", "update", "doctor", "restore", "uninstall", "quality", "browser"];
+declare const COMMANDS: readonly ["install", "models", "update", "doctor", "restore", "uninstall", "quality", "browser"];
 type Command = (typeof COMMANDS)[number];
 interface Flags {
     agents: SelectableRuntimeId[];

package/dist/cli.js

@@ -2480,7 +2480,7 @@ function assertCompatibleContext7(server, value) {
 function ensureObject(parent, key, fieldPath) {
   if (parent[key] === void 0) parent[key] = {};
   const value = objectValue(parent[key]);
-  if (value === null) throw new Error(`OpenCode: '${fieldPath}' debe ser un objeto; corr\xEDgelo antes de reintentar sync.`);
+  if (value === null) throw new Error(`OpenCode: '${fieldPath}' debe ser un objeto; corr\xEDgelo antes de reintentar install.`);
   return value;
 }
 function ensureOwnedPrimaryObject(parent, key, field, owned, changes) {
@@ -2921,7 +2921,7 @@ ${gitReadCommands.map((command) => `- \`${command}\``).join("\n")}
         const content = upsertJson(contentSource, (root) => {
           const rawMcp = root["mcp"];
           if (rawMcp !== void 0 && objectValue(rawMcp) === null) {
-            throw new Error("OpenCode: la clave 'mcp' debe ser un objeto; corr\xEDgela antes de reintentar sync.");
+            throw new Error("OpenCode: la clave 'mcp' debe ser un objeto; corr\xEDgela antes de reintentar install.");
           }
           const existingMcp = rawMcp;
           const context7 = canonical.servers.context7;
@@ -2933,7 +2933,7 @@ ${gitReadCommands.map((command) => `- \`${command}\``).join("\n")}
               primaryModelOwnership.push({ field: PRIMARY_MODEL_FIELD, owned: true });
             }
           } else if (typeof root[PRIMARY_MODEL_FIELD] !== "string" || root[PRIMARY_MODEL_FIELD].trim() === "") {
-            throw new Error("OpenCode: 'model' debe ser un identificador provider/model no vac\xEDo; corr\xEDgelo antes de reintentar sync.");
+            throw new Error("OpenCode: 'model' debe ser un identificador provider/model no vac\xEDo; corr\xEDgelo antes de reintentar install.");
           }
           const provider = ensureOwnedPrimaryObject(root, "provider", PRIMARY_PROVIDER_FIELD, ctx.ownedPrimaryModelFields, primaryModelOwnership);
           const openai = ensureOwnedPrimaryObject(provider, "openai", PRIMARY_OPENAI_FIELD, ctx.ownedPrimaryModelFields, primaryModelOwnership);
@@ -3001,7 +3001,7 @@ ${gitReadCommands.map((command) => `- \`${command}\``).join("\n")}
             if (server.transport === "stdio") {
               if (server.command === "{{ENGRAM_BIN}}" && ctx.engramBin === null) {
                 ctx.warnings.push(
-                  "Engram no detectado: el MCP 'engram' no se registra. Inst\xE1lalo (github.com/Gentleman-Programming/engram) y re-ejecuta sync."
+                  "Engram no detectado: el MCP 'engram' no se registra. Inst\xE1lalo (github.com/Gentleman-Programming/engram) y re-ejecuta install."
                 );
                 continue;
               }
@@ -3600,7 +3600,7 @@ ${agent.body}`,
         const content = upsertJson(readMcpConfig2(file), (root) => {
           const rawServers = root["mcpServers"];
           if (rawServers !== void 0 && !isRecord3(rawServers)) {
-            throw new Error("Claude Code: la clave 'mcpServers' debe ser un objeto; corr\xEDgela antes de reintentar sync.");
+            throw new Error("Claude Code: la clave 'mcpServers' debe ser un objeto; corr\xEDgela antes de reintentar install.");
           }
           const existingServers = rawServers;
           const context7 = canonical.servers.context7;
@@ -3639,7 +3639,7 @@ ${agent.body}`,
             if (server.transport === "stdio") {
               if (server.command === "{{ENGRAM_BIN}}" && ctx.engramBin === null) {
                 ctx.warnings.push(
-                  "Engram no detectado: el MCP 'engram' no se registra. Inst\xE1lalo (github.com/Gentleman-Programming/engram) y re-ejecuta sync."
+                  "Engram no detectado: el MCP 'engram' no se registra. Inst\xE1lalo (github.com/Gentleman-Programming/engram) y re-ejecuta install."
                 );
                 continue;
               }
@@ -4308,7 +4308,7 @@ ${body}`
           if (server.transport === "stdio") {
             if (server.command === "{{ENGRAM_BIN}}" && ctx.engramBin === null) {
               ctx.warnings.push(
-                "Engram no detectado: el MCP 'engram' no se registra. Inst\xE1lalo (github.com/Gentleman-Programming/engram) y re-ejecuta sync."
+                "Engram no detectado: el MCP 'engram' no se registra. Inst\xE1lalo (github.com/Gentleman-Programming/engram) y re-ejecuta install."
               );
               continue;
             }
@@ -10181,7 +10181,7 @@ async function runInstall(opts) {
           }
           if (promptReconciliationFailed) {
             exitCode = 1;
-            p.log.error("Playwright CLI y navegador se han instalado y la preferencia qued\xF3 activa, pero la gu\xEDa de navegador qued\xF3 en estado parcial. Ejecuta 'jorgex-stack sync' para repararla.");
+            p.log.error("Playwright CLI y navegador se han instalado y la preferencia qued\xF3 activa, pero la gu\xEDa de navegador qued\xF3 en estado parcial. Ejecuta 'jorgex-stack install' para repararla.");
           } else {
             const verified = verifiedCapability ?? (preparedEnv === void 0 ? inspectPlaywrightCapability({ browserVerified: true, expectedVersion: candidate.version }) : inspectPlaywrightCapability({ browserVerified: true, env: preparedEnv, expectedVersion: candidate.version }));
             if (verified.effective && verified.cli.status === "current" && verified.cli.binPath !== null && verified.cli.detectedVersion !== null && verified.browserCache.status === "ready") {
@@ -15221,7 +15221,7 @@ function readDoctorTextIfExists(file) {
   }
 }
 var STALE_PERMISSIONS_MARKER = "differs from the stack default and was left untouched";
-var UPGRADE_PERMISSIONS_REMEDY = "jorgex-stack sync --upgrade-permissions --dry-run";
+var UPGRADE_PERMISSIONS_REMEDY = "jorgex-stack install --upgrade-permissions --dry-run";
 function piAgentDir(targetDir) {
   return targetDir === void 0 ? process.env.PI_CODING_AGENT_DIR ?? path41.join(HOME, ".pi", "agent") : path41.join(targetDir, "pi-agent");
 }
@@ -15258,7 +15258,7 @@ function reportPiPermissions(targetDir) {
   }
   if (receipt !== null) return 0;
   p3.log.warn(
-    `Pi: permission policy present without package ownership (${configFile}) and left untouched; Stack never rewrites Pi state \u2014 align it by hand or remove it so a later 'jorgex-stack sync --agents pi' can seed the package default.`
+    `Pi: permission policy present without package ownership (${configFile}) and left untouched; Stack never rewrites Pi state \u2014 align it by hand or remove it so a later 'jorgex-stack install --agents pi' can seed the package default.`
   );
   return 1;
 }
@@ -15288,7 +15288,7 @@ function reportWritingStyle(options, style, mode) {
   p3.log.info(`Estilo de escritura incluido: ${style.canonicalPath}; fuente local ${style.sourcePath}; tama\xF1o ${Buffer.byteLength(style.content, "utf8")} bytes de texto normalizado. La carga nativa no est\xE1 verificada.`);
   if (style.originalContent === style.installedContent) p3.log.success("Archivo local de estilo actualizado con el canon incluido.");
   else {
-    p3.log.warn(`Archivo local de estilo ${style.originalContent === null ? "pendiente de instalar" : "desactualizado; pendiente de sincronizar"}; ejecuta install o sync (${style.sourcePath}).`);
+    p3.log.warn(`Archivo local de estilo ${style.originalContent === null ? "pendiente de instalar" : "desactualizado; pendiente de sincronizar"}; ejecuta install (${style.sourcePath}).`);
     problems++;
   }
   const expected = mode.mode !== "programmatic" ? upsertMarkdownSection(null, "writing-style", style.content).trim() : null;
@@ -15307,7 +15307,7 @@ function reportWritingStyle(options, style, mode) {
       const matches = expected === null ? !content.includes(open) && !content.includes(close) : healthy && block === expected;
       if (matches) p3.log.success(`${id}: proyecci\xF3n de estilo coincide (${file})${mode.mode === "programmatic" ? "; omitida en modo programmatic" : ""}.`);
       else {
-        p3.log.warn(`${id}: proyecci\xF3n de estilo desactualizada o ausente (${file}); ejecuta sync.`);
+        p3.log.warn(`${id}: proyecci\xF3n de estilo desactualizada o ausente (${file}); ejecuta install.`);
         problems++;
       }
       if (id === "codex") {
@@ -15493,7 +15493,7 @@ async function runDoctor(options = {}) {
       problems++;
     }
     if (pending > 0) {
-      p3.log.warn(`${adapter.name}: ${pending} archivos gestionados desactualizados o ausentes \u2192 ejecuta 'sync'.`);
+      p3.log.warn(`${adapter.name}: ${pending} archivos gestionados desactualizados o ausentes \u2192 ejecuta 'install'.`);
       problems++;
     } else if (!stalePermissions) {
       p3.log.success(`${adapter.name}: config del stack al d\xEDa (${detection.configDir}).`);
@@ -15501,7 +15501,7 @@ async function runDoctor(options = {}) {
     const prev = manifest.runtimes[adapter.id];
     const orphans = prev && current.complete ? findOrphans(prev.owned, current.targets) : [];
     if (orphans.length > 0) {
-      p3.log.warn(`${adapter.name}: ${orphans.length} archivos hu\xE9rfanos de versiones previas \u2192 ejecuta 'sync'.`);
+      p3.log.warn(`${adapter.name}: ${orphans.length} archivos hu\xE9rfanos de versiones previas \u2192 ejecuta 'install'.`);
       problems++;
     }
     if (adapter.id === "codex" && fs34.existsSync(path41.join(detection.configDir, "hooks.json"))) {
@@ -21954,8 +21954,8 @@ async function completeProjection(operation, packageResult, deps) {
   }
   return projectionResult.kind === "blocked" ? projectionResult : packageResult;
 }
-var INSTALL_INIT_REMEDY = "Corrige la causa y ejecuta sync --agents pi para completar la inicializaci\xF3n.";
-var INSTALL_INIT_TARGET_REMEDY = "Corrige la causa y ejecuta sync --agents pi con el mismo --target-dir para completar la inicializaci\xF3n.";
+var INSTALL_INIT_REMEDY = "Corrige la causa y ejecuta install --agents pi para completar la inicializaci\xF3n.";
+var INSTALL_INIT_TARGET_REMEDY = "Corrige la causa y ejecuta install --agents pi con el mismo --target-dir para completar la inicializaci\xF3n.";
 function withInstallInitRemedy(result, fallbackRemedy) {
   return result.remedy === void 0 ? { kind: "blocked", reason: result.reason, remedy: fallbackRemedy } : result;
 }
@@ -22025,7 +22025,7 @@ function managedPackageResult(result) {
   if (result.kind === "manual-existing") {
     return {
       kind: "manual-existing",
-      remedy: result.remedy ?? "Pi ya est\xE1 configurado manualmente; conserva esa configuraci\xF3n o elim\xEDnala antes de ejecutar sync --agents pi."
+      remedy: result.remedy ?? "Pi ya est\xE1 configurado manualmente; conserva esa configuraci\xF3n o elim\xEDnala antes de ejecutar install --agents pi."
     };
   }
   if (result.kind === "models") return { kind: "models", models: result.models };
@@ -22602,7 +22602,7 @@ async function runManagedPiSystem(input) {
       return Promise.resolve(result2.kind === "drift" ? {
         kind: "drift",
         paths: result2.paths,
-        remedy: "Ejecuta sync --agents pi para reparar la proyecci\xF3n de Pi."
+        remedy: "Ejecuta install --agents pi para reparar la proyecci\xF3n de Pi."
       } : result2);
     },
     prepareProjectionUninstall() {
@@ -22673,7 +22673,7 @@ async function runManagedPiSystem(input) {
             return {
               kind: "blocked",
               reason: "native-checker-conflict",
-              remedy: "El paquete Pi qued\xF3 activado; la comprobaci\xF3n nativa detect\xF3 un conflicto de propiedad sobre mcp.json/autoridad. Resu\xE9lvelo y ejecuta sync --agents pi para completar la inicializaci\xF3n."
+              remedy: "El paquete Pi qued\xF3 activado; la comprobaci\xF3n nativa detect\xF3 un conflicto de propiedad sobre mcp.json/autoridad. Resu\xE9lvelo y ejecuta install --agents pi para completar la inicializaci\xF3n."
             };
           }
           const expectedClaims = nativeAuthority === void 0 ? previousNativeClaimNames(nativeHomeDir, authorityRaw) ?? [] : Object.keys(nativeAuthority.entries);
@@ -22689,7 +22689,7 @@ async function runManagedPiSystem(input) {
           return {
             kind: "blocked",
             reason: "native-checker-failed",
-            remedy: `El paquete Pi qued\xF3 activado; la comprobaci\xF3n nativa fall\xF3: ${error instanceof Error ? error.message : String(error)}. Inicializaci\xF3n nativa pendiente; ejecuta sync --agents pi para reintentar.`
+            remedy: `El paquete Pi qued\xF3 activado; la comprobaci\xF3n nativa fall\xF3: ${error instanceof Error ? error.message : String(error)}. Inicializaci\xF3n nativa pendiente; ejecuta install --agents pi para reintentar.`
           };
         }
       }
@@ -23750,7 +23750,7 @@ async function installMissingEngram(options = {}) {
 
 // src/cli.ts
 var VERSION = readPackageVersion();
-var COMMANDS = ["install", "sync", "models", "update", "doctor", "restore", "uninstall", "quality", "browser"];
+var COMMANDS = ["install", "models", "update", "doctor", "restore", "uninstall", "quality", "browser"];
 var QUALITY_REJECTED_VALUE_FLAGS = /* @__PURE__ */ new Set([
   "--agents",
   "--playwright-runtimes",
@@ -23759,15 +23759,15 @@ var QUALITY_REJECTED_VALUE_FLAGS = /* @__PURE__ */ new Set([
   "--mode",
   "--subagent-concurrency"
 ]);
-async function ensureOpenCodeModelsForInstall(command, flags, runtimes) {
+async function ensureOpenCodeModelsForInstall(flags, runtimes) {
   if (!runtimes.includes("opencode") || loadModelMap().opencode) return true;
-  const canPrompt = command === "install" && !flags.yes && !flags.dryRun && process.stdout.isTTY;
+  const canPrompt = !flags.yes && !flags.dryRun && process.stdout.isTTY;
   if (canPrompt) {
     const code = await runModelsPicker({ yes: false, runtimes: ["opencode"] });
     if (code === 0 && loadModelMap().opencode) return true;
   }
   console.error(
-    "OpenCode no tiene modelos configurados. Ejecuta 'jorgex-stack models --agents opencode' de forma interactiva antes de install/sync."
+    "OpenCode no tiene modelos configurados. Ejecuta 'jorgex-stack models --agents opencode' de forma interactiva antes de install."
   );
   return false;
 }
@@ -23895,7 +23895,7 @@ Corrige o borra ${preferenceFile}, o vuelve a ejecutar con --mode human|programm
     }
   }
   if (!promptIfMissing) {
-    console.error("No hay modo guardado; usa --mode expl\xEDcito para este sync.");
+    console.error("No hay modo guardado; usa --mode expl\xEDcito para esta aplicaci\xF3n.");
     process.exitCode = 1;
     return null;
   }
@@ -23929,7 +23929,7 @@ Corrige o borra ${preferenceFile}, o vuelve a ejecutar con --mode human|programm
     subagentConcurrency: concurrency
   };
 }
-async function resolvePlaywrightToolConsent(command, flags, runtimes) {
+async function resolvePlaywrightToolConsent(flags, runtimes) {
   const interactive = Boolean(process.stdout.isTTY);
   const supportsPiPlaywright = PI_RUNTIME_CANDIDATE.contract.capabilities.includes("playwright-handoff-v1");
   const supported = runtimes.filter((runtime) => runtime !== "pi" || supportsPiPlaywright);
@@ -23949,13 +23949,13 @@ async function resolvePlaywrightToolConsent(command, flags, runtimes) {
       return null;
     }
   }
-  if (command === "install" && flags.playwright && supported.length === 0 && runtimes.includes("pi")) {
+  if (flags.playwright && supported.length === 0 && runtimes.includes("pi")) {
     console.error("Pi no declara el handoff Playwright requerido.");
     process.exitCode = 1;
     return null;
   }
   let confirmed = false;
-  if (command === "install" && interactive && !flags.yes && !flags.dryRun && flags.targetDir === void 0) {
+  if (interactive && !flags.yes && !flags.dryRun && flags.targetDir === void 0) {
     const answer = await p6.confirm({
       message: "Recomendado: \xBFinstalar Playwright CLI gestionado y descargar Chromium?",
       initialValue: false
@@ -23965,7 +23965,7 @@ async function resolvePlaywrightToolConsent(command, flags, runtimes) {
   }
   let runtimeSelection;
   const approved = interactive && !flags.yes ? confirmed : flags.yes && flags.playwright;
-  if (command === "install" && approved && supported.length > 0) {
+  if (approved && supported.length > 0) {
     let selected = flags.playwrightRuntimes ?? supported;
     if (interactive && !flags.yes && !flags.dryRun && flags.targetDir === void 0 && flags.playwrightRuntimes === void 0) {
       const answer = await p6.multiselect({
@@ -23980,7 +23980,7 @@ async function resolvePlaywrightToolConsent(command, flags, runtimes) {
     runtimeSelection = Object.fromEntries(supported.map((runtime) => [runtime, selected.includes(runtime)]));
   }
   return {
-    command,
+    command: "install",
     interactive,
     yes: flags.yes,
     targetDir: flags.targetDir !== void 0,
@@ -23989,7 +23989,7 @@ async function resolvePlaywrightToolConsent(command, flags, runtimes) {
     ...runtimeSelection === void 0 ? {} : { runtimeSelection }
   };
 }
-async function resolveDevtoolsMcpSelection(command, flags, runtimes) {
+async function resolveDevtoolsMcpSelection(flags, runtimes) {
   if (flags.devtools && flags.noDevtools) {
     console.error("Usa solo uno de --devtools o --no-devtools.");
     process.exitCode = 1;
@@ -23998,7 +23998,7 @@ async function resolveDevtoolsMcpSelection(command, flags, runtimes) {
   if (flags.devtools || flags.noDevtools) {
     return Object.fromEntries(runtimes.map((runtime) => [runtime, flags.devtools]));
   }
-  if (command !== "install" || flags.yes || flags.dryRun || flags.targetDir !== void 0 || !process.stdout.isTTY) {
+  if (flags.yes || flags.dryRun || flags.targetDir !== void 0 || !process.stdout.isTTY) {
     return {};
   }
   const file = devtoolsMcpPreferenceFile();
@@ -24199,7 +24199,6 @@ Uso: pnpm dlx jorgex-stack [comando] [opciones]
 
 Comandos:
   install     Instala el stack; OpenCode fresh exige elegir modelos conectados
-  sync        Re-aplica la config y el model-map existente (idempotente; sin picker)
   models      Picker por tier o subagente (OpenCode: 'opencode models' en vivo)
   update      --check: compara stack/Engram/skills con sus upstreams
   doctor      Estado: Engram, drift de config, hooks de Codex, key de context7
@@ -24219,9 +24218,9 @@ Opciones:
   --yes, -y             No interactivo
   --playwright          Autoriza Playwright CLI gestionado y Chromium (requerido con --yes/sin TTY)
   --engram              (install) autoriza instalar el binario Engram si falta
-  --devtools            (install/sync) activa Chrome DevTools MCP para los runtimes destino (opt-in)
-  --no-devtools         (install/sync) desactiva Chrome DevTools MCP (incompatible con --devtools)
-  --upgrade-permissions (install/sync) re-aplica permisos gestionados sobre config existente (opt-in)
+  --devtools            (install) activa Chrome DevTools MCP para los runtimes destino (opt-in)
+  --no-devtools         (install) desactiva Chrome DevTools MCP (incompatible con --devtools)
+  --upgrade-permissions (install) re-aplica permisos gestionados sobre config existente (opt-in)
   --engram-typebox-compat (install/update con Pi) opt-in expl\xEDcito a la variante temporal #1567;
                         sin el flag no se adquiere ni persiste ninguna preferencia
   --remove-engram       (uninstall) desregistra Engram de los runtimes;
@@ -24329,9 +24328,8 @@ Flags disponibles: jorgex-stack --help`
       }
       return;
     }
-    case "install":
-    case "sync": {
-      const runtimes = await resolveRuntimes(flags, command === "install");
+    case "install": {
+      const runtimes = await resolveRuntimes(flags, true);
       if (runtimes === null) return;
       if (runtimes.length === 0) {
         console.error("Ning\xFAn runtime detectado (opencode, claude-code, codex, pi).");
@@ -24363,12 +24361,12 @@ Flags disponibles: jorgex-stack --help`
         }
         const mode = fileRuntimes.length > 0 || flags.mode !== void 0 || flags.subagentConcurrency !== void 0 ? await resolveInstallMode(flags) : void 0;
         if (mode === null) return;
-        const devtoolsMcpSelection = await resolveDevtoolsMcpSelection(command, flags, runtimes);
+        const devtoolsMcpSelection = await resolveDevtoolsMcpSelection(flags, runtimes);
         if (devtoolsMcpSelection === null) {
           exitCode = process.exitCode === 1 ? 1 : 0;
           return;
         }
-        const playwrightToolConsent = await resolvePlaywrightToolConsent(command, flags, runtimes);
+        const playwrightToolConsent = await resolvePlaywrightToolConsent(flags, runtimes);
         if (playwrightToolConsent === null) {
           exitCode = process.exitCode === 1 ? 1 : 0;
           return;
@@ -24380,20 +24378,17 @@ Flags disponibles: jorgex-stack --help`
         };
         p6.log.info(`Estilo de escritura: ${writingStyle.sourcePath}${flags.dryRun ? " (instalaci\xF3n prevista; sin escrituras)" : ""}.`);
         applyWritingStyle(writingStyle, flags.dryRun);
-        if (!await ensureOpenCodeModelsForInstall(command, flags, fileRuntimes)) {
+        if (!await ensureOpenCodeModelsForInstall(flags, fileRuntimes)) {
           exitCode = 1;
           return;
         }
-        let engramBin;
-        if (command === "install") {
-          const engram = await resolveHostEngramForInstall(flags);
-          if (!engram.ok) {
-            p6.log.error(engram.message);
-            exitCode = 1;
-            return;
-          }
-          engramBin = engram.bin;
+        const engram = await resolveHostEngramForInstall(flags);
+        if (!engram.ok) {
+          p6.log.error(engram.message);
+          exitCode = 1;
+          return;
         }
+        const engramBin = engram.bin;
         if (fileRuntimes.length > 0) {
           exitCode = await runInstall({
             runtimes: fileRuntimes,
@@ -24414,7 +24409,7 @@ Flags disponibles: jorgex-stack --help`
           });
         }
         let piCanRun = true;
-        if (command === "install" && fileRuntimes.length === 0 && runtimes.includes("pi") && playwrightToolPlan.actions.length > 0) {
+        if (fileRuntimes.length === 0 && runtimes.includes("pi") && playwrightToolPlan.actions.length > 0) {
           if (flags.dryRun) {
             p6.log.info("Playwright CLI: instalaci\xF3n global y navegador previstos (dry-run; no se ejecutan).");
           } else {
@@ -24439,7 +24434,7 @@ Flags disponibles: jorgex-stack --help`
           } else {
             const piExitCode = await runSelectedPi({
               operation: command,
-              ...command === "install" && playwrightToolConsent.interactive && !flags.yes && flags.targetDir === void 0 && !playwrightToolConsent.confirmed ? { playwrightRefresh: false } : {},
+              ...playwrightToolConsent.interactive && !flags.yes && flags.targetDir === void 0 && !playwrightToolConsent.confirmed ? { playwrightRefresh: false } : {},
               targetDir: flags.targetDir,
               yes: flags.yes,
               resolvedEngramBin: flags.targetDir === void 0 ? engramBin : void 0,
@@ -24643,9 +24638,9 @@ Flags disponibles: jorgex-stack --help`
         }));
       }
       if (result.syncRequired && fileRuntimes.length > 0 && (result.exitCode !== 0 || !canSync)) {
-        p6.log.warn("Skills/stack actualizados, pero el sync con los runtimes sigue pendiente. Ejecuta jorgex-stack sync --mode human|programmatic.");
+        p6.log.warn("Skills/stack actualizados, pero su aplicaci\xF3n a los runtimes sigue pendiente. Ejecuta jorgex-stack install --mode human|programmatic.");
       } else if (!playwrightReconciled && result.exitCode === 0 && result.syncRequired && fileRuntimes.length > 0 && canSync && !flags.yes && process.stdout.isTTY) {
-        const apply = await p6.confirm({ message: "\xBFRe-aplicar a los runtimes ahora? (sync)" });
+        const apply = await p6.confirm({ message: "\xBFRe-aplicar a los runtimes ahora?" });
         if (!p6.isCancel(apply) && apply) {
           process.exitCode = await runInstall({
             runtimes: fileRuntimes,
@@ -24657,10 +24652,10 @@ Flags disponibles: jorgex-stack --help`
             ...updateCapability === void 0 ? {} : { playwrightCapability: updateCapability }
           });
         } else {
-          console.log("Sin aplicar. Cuando quieras: jorgex-stack sync");
+          console.log("Sin aplicar. Cuando quieras: jorgex-stack install");
         }
       } else if (result.exitCode === 0 && result.syncRequired && fileRuntimes.length > 0 && canSync && (flags.yes || !process.stdout.isTTY)) {
-        console.log("Skills/stack actualizados. Ejecuta jorgex-stack sync para aplicarlos a los runtimes.");
+        console.log("Skills/stack actualizados. Ejecuta jorgex-stack install para aplicarlos a los runtimes.");
       }
       if (runtimes.includes("pi")) {
         persistSuccessfulGlobalMode(mode, flags.targetDir, flags.dryRun, process.exitCode ?? result.exitCode);
@@ -24680,14 +24675,14 @@ Flags disponibles: jorgex-stack --help`
       if (runtimes.includes("pi")) code = Math.max(code, await runSelectedPi({ operation: "models", targetDir: flags.targetDir }));
       process.exitCode = code;
       if (code === 0 && fileRuntimes.length > 0 && !flags.yes && process.stdout.isTTY) {
-        const apply = await p6.confirm({ message: "\xBFAplicar ahora los modelos a los agentes instalados? (sync)" });
+        const apply = await p6.confirm({ message: "\xBFAplicar ahora los modelos a los agentes instalados?" });
         if (!p6.isCancel(apply) && apply) {
           const preferenceFile = installModePreferenceFile();
           const explicitMode = flags.mode !== void 0 || flags.subagentConcurrency !== void 0;
           const hasSavedMode = hasInstallModePreference(preferenceFile);
           const canResolveMode = flags.targetDir !== void 0 || explicitMode || hasSavedMode;
           if (!canResolveMode) {
-            p6.log.warn("Model-map guardado: se omite el sync con los runtimes porque falta un modo. Ejecuta jorgex-stack sync --mode human|programmatic.");
+            p6.log.warn("Model-map guardado: su aplicaci\xF3n a los runtimes requiere un modo. Ejecuta jorgex-stack install --mode human|programmatic.");
             return;
           }
           const mode = await resolveInstallMode(flags, false);
@@ -24702,7 +24697,7 @@ Flags disponibles: jorgex-stack --help`
             ...playwrightCapability === void 0 ? {} : { playwrightCapability }
           });
         } else {
-          console.log("Sin aplicar. Cuando quieras: jorgex-stack sync");
+          console.log("Sin aplicar. Cuando quieras: jorgex-stack install");
         }
       }
       return;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jorgex-stack",
-  "version": "1.9.71",
+  "version": "1.9.73",
   "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",

package/stack/agents/test-analyzer.md

@@ -35,13 +35,13 @@ Apply the risk, existing-protection, behavior, seam, and non-duplication rules f
 1. Compare each changed behavior with the actual evidence in existing or changed tests.
 2. Evaluate refactor resistance, determinism, accidental `test.only`/exclusive-focus slips, stable UI semantics, negative cases, and async/concurrency behavior only where relevant to the diff.
 3. Report an actionable gap only when the existing evidence cannot catch a meaningful regression. Name that failure, the test considered, the proposed seam, and its criticality.
-4. Separately flag brittle, redundant, nondeterministic, or implementation-coupled tests worth fixing or removing.
+4. Separately flag brittle, redundant, nondeterministic, or implementation-coupled tests, repeated setup/fixtures/helpers, and suites fragmented by task, delivery or RED/GREEN phase rather than contract. Before supporting Ready, assess whether the assigned test structure can be simplified with equivalent protection and isolation; do not merge setups that protect distinct boundaries. Report structural duplication as a test-quality finding, not a missing-coverage gap; the coordinator routes the fix to its owner.
 
 ## Rating guidelines
 
 - **8–10 — Critical**: Data loss, security issue, system failure, or substantial business/user failure without sufficient evidence
 - **5–7 — Important**: Concrete user-facing, business, or operational regression with moderate impact
-- **1–4**: Not a missing-test finding; mention only a brittle or redundant existing test worth removing
+- **1–4**: Not a missing-test finding; mention only a brittle or redundant test or setup worth simplifying
 
 ## Output format
 
@@ -51,7 +51,7 @@ Apply the risk, existing-protection, behavior, seam, and non-duplication rules f
 4. **Test Quality Issues**: Brittle, redundant, nondeterministic, or implementation-coupled tests
 5. **Positive Observations**: Strong existing decisions and evidence
 
-For every recommendation, state the failure it would catch, why existing protection is insufficient, and why the proposed seam is stronger than another layer.
+For a coverage recommendation, state the failure it would catch, why existing protection is insufficient, and why the proposed seam is stronger than another layer. For a structural quality finding, identify the duplicated preparation, its maintenance cost, the proposed reuse or consolidation, and the contracts and isolation that must remain intact; do not invent missing coverage to justify simplification.
 
 ## Result contract
 

package/stack/agents/tester.md

@@ -19,6 +19,8 @@ Your job is to produce the strongest testing evidence for the risk—not to maxi
 
 Inspect the complete relevant contract (implementation, public API, docs, configuration, and existing tests), then detect the project's real runner, script/command, setup, scope, and helpers. Mirror local naming and assertion conventions; use tooling already installed. Documented project scripts, including `pnpm`, `npm`, and similar package-manager scripts, are valid. Do not add dependencies or invent a second testing stack; prohibit only invoking or resolving a command that could auto-install a missing runner/tool or require interaction without permission. If a needed suite or boundary infrastructure is absent, propose the missing protection or state the limitation rather than turning absence into a no-test decision.
 
+Organize suites by behavior or contract, not by task, delivery or RED/GREEN phase. Before creating another suite or setup, reuse relevant existing helpers and fixtures within the assignment. Share only genuinely common preparation; keep distinct boundaries and state isolation separate. One authoritative seam does not mean one test case: preserve meaningful positive, negative, platform and real-SDK cases.
+
 When time/timezone, randomness/IDs, ordering, shared state, filesystem, or network can affect the evidence, control only the relevant sources with isolated temporary fixtures and cleanup; keep expected-error assertions narrow and unexpected output visible.
 
 Make one explicit testing decision:

package/stack/skills/diagnose/SKILL.md

@@ -23,7 +23,7 @@ Spend disproportionate effort here. **Be aggressive. Be creative. Refuse to give
 
 ### Ways to construct one — try them in roughly this order
 
-Inspect the project's existing runner, fixtures, helpers and diagnostic commands first. Reuse the closest suitable harness; the options below are not an instruction to build a second testing stack. Apply `lean-code`'s diagnostic tooling policy before adding or retaining tooling.
+Inspect the project's existing runner, fixtures, helpers and diagnostic commands first. Reuse the closest suitable harness; the options below are not an instruction to build a second testing stack. Apply [Lean Code's diagnostic tooling policy](../lean-code/SKILL.md#diagnostic-tooling) before adding or retaining tooling.
 
 1. **Failing test** at whatever seam reaches the bug — unit, integration, e2e.
 2. **Curl / HTTP script** against a running dev server.

package/stack/skills/lean-code/SKILL.md

@@ -62,7 +62,7 @@ Prefer the narrowest change that solves the real need.
 
 ### Diagnostic tooling
 
-Reuse the project's runner, fixtures, helpers and existing diagnostic commands before building a harness. New probes, replay scripts and diagnostic harnesses are temporary by default, with explicit resource ownership and automatic teardown arranged before execution. Keep tooling only for a concrete recurring need: identify its consumer, why the existing harness cannot cover it, and who maintains it in the current task or PR. A successful one-off investigation alone does not justify a permanent command, framework or dependency. Preserve the authoritative regression test and compact reproduction evidence, not the disposable environment.
+Reuse the project's runner, fixtures, helpers and existing diagnostic commands before building a harness. New probes, replay scripts and diagnostic harnesses are temporary by default, with explicit resource ownership and automatic teardown arranged before execution. Keep tooling only for a concrete recurring need within the approved scope: identify its consumer, why the existing harness cannot cover it, and who maintains it in the current task or PR. Seek approval if retaining it expands the scope. A successful one-off investigation alone does not justify a permanent command, framework or dependency. Preserve the authoritative regression test and compact reproduction evidence, not the disposable environment; do not remove meaningful permission, concurrency or deletion protection just to shrink the diff.
 
 ### Review / simplification
 

package/stack/skills/to-prd/SKILL.md

@@ -29,7 +29,7 @@ The solution to the problem, from the user's perspective.
 
 ## User Stories
 
-A LONG, numbered list of user stories. Each user story should be in the format of:
+A numbered list of user stories proportional to the approved scope. Each user story should be in the format of:
 
 1. As an <actor>, I want a <feature>, so that <benefit>
 
@@ -37,7 +37,7 @@ A LONG, numbered list of user stories. Each user story should be in the format o
 1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending
 </user-story-example>
 
-This list of user stories should be extremely extensive and cover all aspects of the feature.
+Include only the actors, behaviors and relevant boundary cases supported by the context. Do not invent speculative requirements or pad the list to meet a length target. A small feature may need only one story.
 
 ## Clarifications
 

package/stack/skills/work-audit/SKILL.md

@@ -33,7 +33,7 @@ Check:
 3. Every SC is verifiable and has task coverage in the plan table.
 4. Every formal task resolves and verifies its declared `Spec` reference, task identity and access before execution. An identity mismatch, missing source or absent access is a blocking `gaps` verdict; never reconstruct a missing spec from the PRD.
 5. Every task references known SCs and has one agent, one bounded scope, affected files, dependencies and a wave consistent with those dependencies.
-6. Each behavior-changing task has a complete testing decision: risk, existing protection, new behavior, chosen seam and action.
+6. Each behavior-changing task has a complete testing decision: risk, existing protection, new behavior, chosen seam and action. Apply the testing value check below to the proposed protection.
 7. PR scopes, bases and ordering are compatible with the task dependencies.
 8. PRD, plan and task specs do not contradict each other or duplicate status/evidence into a second home.
 
@@ -53,7 +53,7 @@ Check:
 3. Every in-scope SC has concrete evidence in its canonical checkpoint: command/setup, scope, result and relevant limits.
 4. The implementation diff and observed behavior stay within the approved PRD, plan and task scopes.
    - POST cannot legitimize scope changes retroactively. For intentional material contract changes, send scope drift to SPEC through change-first. Defects or bugfixes restoring the approved contract return to EXECUTE.
-5. Tests, typecheck/build, manual checks and external gates are not over-claimed; missing or incomplete execution remains explicit.
+5. Tests, typecheck/build, manual checks and external gates are not over-claimed; missing or incomplete execution remains explicit. Apply the testing value check below to the implemented protection and actual evidence.
 6. No accepted requirement, edge case, testing decision, documentation change or cross-repo contract assigned to the current checkpoint is left without implementation or evidence. Future checkpoints remain out of scope.
 
 POST verdicts:
@@ -61,6 +61,16 @@ POST verdicts:
 - `converged` — the available evidence satisfies the approved contract. This does not replace tests, human review, configured Quality Gates or manual validation when applicable.
 - `gaps` — return actionable findings to the orchestrator and route each to its owning phase; never send every gap unconditionally to EXECUTE. Rerun POST after the fix.
 
+## Testing value check — PRE and POST
+
+For each added or strengthened test, ask: "What concrete regression does this test detect that existing coverage does not?" PRE checks the proposed answer; POST checks that the actual assertions and evidence support it. Another layer must protect a distinct contract, not repeat the same behavior.
+
+For a mechanical test update, `reuse` or `no new test`, check the identified existing protection or other verification and why it is sufficient. Do not demand a new test, extra coverage or a manufactured RED when the risk is already covered.
+
+A RED for behavioral protection must fail because the asserted behavior is wrong or missing, not merely because a source string is absent. Structural assertions are valid when structure is itself the contract, such as triggers, permissions, secret handling or suite registration; distinguish that guarantee from runtime behavior and avoid freezing an incidental command recipe, internal ordering or full implementation.
+
+Keep this check within the checkpoint's changed behavior and relevant coverage; do not turn it into a suite-wide audit.
+
 ## Read-only boundary
 
 - Do not write, edit or modify the PRD, plan, task specs, memory, code, tests, checkboxes or PR state.

package/stack/skills/work-lifecycle/references/plan-template.md

@@ -76,7 +76,8 @@ Every formal task has exactly one recoverable `Spec` reference in the plan table
 | 03 | 02 | [agent] | [bounded scope] | [one declared source] | [descriptive name] | [one-line description] | SC-01 | ⬜ | 2 | 01 |
 | 04 | 02 | [agent] | [bounded scope] | [one declared source] | [descriptive name] | [one-line description] | SC-02 | ⬜ | 2 | 01, 02 |
 
-**Statuses**: ⬜ Pending → 🔴 RED → 🟢 GREEN → 🔍 Review → ✅ Done
+**Statuses**: ⬜ Pending → In progress → Verified → 🔍 Review → ✅ Done
+For test-first work that adds or strengthens protection, use 🔴 RED → 🟢 GREEN within In progress. Tasks using `reuse` or `no new test` proceed with their chosen verification; do not require a new failing test to advance.
 ```
 
 ---
@@ -111,7 +112,7 @@ Use this adaptable content in the one source declared by the plan's `Spec` colum
 - **Existing protection**: [specific existing test/evidence, or none]
 - **New behavior**: [behavior needing new protection, or none]
 - **Chosen seam**: [closest authoritative seam and why]
-- **Action**: [add | update | reuse | no new test] — [concrete reason]
+- **Action**: [add | update | reuse | no new test] — [for new or stronger protection, the concrete regression existing coverage misses; for a mechanical test update, reuse or no new test, why existing protection or other verification is sufficient]
 ```
 
 Use only the headings and fields that are pertinent, except retain the complete testing decision when the task changes behavior. Do not require literal code, input/output blocks or empty heading, section or field. Existing Engram task observations remain compatible; adapt this template only for newly created or materially revised specs.
@@ -137,11 +138,11 @@ Mutation is serialized: the coordinator is the single writer, reads the exact ob
 
 ### Atomicity
 
-- **Max ~5 implementation steps** per task. If more → split into two tasks.
+- Bound each task by an independently verifiable behavior or contract and its concrete regression risk. Keep the layers needed for that outcome together; split when outcomes can be verified independently or coupling and risk warrant it, not at a fixed step count.
 
 ### Structure
 
-- **Natural order**: data layer → generated types → services/hooks → components/UI.
+- **Vertical slices**: organize tasks by behavior and risk, not by technical layer. Sequence implementation within a task by its real dependencies; data, types, services and UI are not mandatory separate tasks.
 - **Numbering**: `01`, `02`, `03`... (two digits) — shared by the plan table row and the topic_key.
 
 ### Context
@@ -154,7 +155,7 @@ Mutation is serialized: the coordinator is the single writer, reads the exact ob
 
 - **VERIFIABLE**: "the type includes X", not "the type is correct".
 - **SPECIFIC**: no copy-paste of generic criteria.
-- **COMPLETE**: cover happy path, edge cases and errors.
+- **COMPLETE**: cover the relevant happy path, boundary cases and errors for the approved contract and concrete risk; do not manufacture speculative scenarios.
 
 ### Constraints