pantheon-opencode 1.5.2 → 1.6.0-beta.2

package/README.md

@@ -10,7 +10,7 @@ want useful structure without giving up control of their code.
 
 [![Version](https://img.shields.io/github/v/release/ils15/pantheon-opencode?label=version)](https://github.com/ils15/pantheon-opencode/releases/latest)
 [![CI](https://img.shields.io/github/actions/workflow/status/ils15/pantheon-opencode/ci.yml?branch=main&label=CI)](https://github.com/ils15/pantheon-opencode/actions)
-[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.22306637.svg)](https://doi.org/10.5281/zenodo.22306637)
+[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.22650136.svg)](https://doi.org/10.5281/zenodo.22650136)
 
 ## What is it?
 
@@ -78,11 +78,14 @@ clear handoff between stages of work.
 
 ## Status
 
-Operational checkout version: **v1.5.0-beta.2** (candidate; publication is not
-asserted here). Pantheon is designed for OpenCode and depends on the
-availability and configuration of OpenCode and any optional services you choose
-to use. Check the [releases](https://github.com/ils15/pantheon-opencode/releases)
-and [changelog](CHANGELOG.md) for the latest published changes.
+Candidate version: the manifests in this checkout express the version being
+prepared, not a confirmed publication. A beta is published only after the
+Release workflow completes successfully. To check which version is actually
+published, consult the npm `beta` dist-tag. Pantheon is designed for OpenCode
+and depends on the availability and configuration of OpenCode and any optional
+services you choose to use. Check the
+[releases](https://github.com/ils15/pantheon-opencode/releases) and
+[changelog](CHANGELOG.md) for the latest published changes.
 
 ## Delegation (native `task()`)
 
@@ -132,6 +135,10 @@ only when they are explicitly approved. Approval is recorded in
 - **Hash mismatch → `CORRUPT_DATA`.** The SHA-256 of the file on disk must
   match the manifest entry, so edits after approval are detected.
 
+Session persistence is provided by the persistence MCP server. The bundled
+code-mode payload contains execution helpers only and does not export or back
+up a database.
+
 Approve or re-approve a script with the `approve_code_script` MCP tool:
 
 ```
@@ -153,28 +160,25 @@ once a project directory is selected, a missing or corrupt manifest fails
 closed instead of falling back. `doctor` validates the manifest and every
 script's SHA-256 without regenerating it.
 
+The local `.pantheon/code-mode/eval-*.py` helpers and any Promptfoo/evaluation
+assets are development-only inputs and are excluded from the npm tarball and
+from the runtime manifest. `src/mcp/eval_store.py` is different: it is a
+shipped runtime dependency of the MCP resources server, not an evaluation
+asset, so it remains packaged.
+
 
-## What's new in 1.5.0-beta.2
+## What's new in 1.6.0-beta.1
 
-- OpenCode-only installer: platform guides consolidated into a single
-  [OpenCode guide](docs/platforms/opencode.md).
-- New `uninstall` CLI with project and global scopes and ownership checks:
-  `node scripts/uninstall.mjs --project|--global [--dry-run] [--force]`.
-- Hardened MCP resources: fixed `pantheon://agents` listing and added
-  symlink/traversal protection for resource paths.
-- OpenCode V2 compatibility: `plugins` / `mcp.servers.enabled` config merge
-  and PWD-correct stdio MCP launch.
-- Expanded `doctor` and install health checks.
-- Sandbox validator for global installs (`scripts/test-opencode-v1-v2-sandbox.sh`)
-  covering OpenCode V1/V2 side by side — see
-  [Sandbox validation](#sandbox-validation-v1v2).
-- Beta2 agent-economy policy: direct native delegation, bounded compaction
-  carry-forward, compact context encoding, and quality floors.
-- A `--prompts` installer flag is planned for a future release.
+- First beta compatible with the OpenCode 2 plugin contract.
+- Removed the legacy vector-memory pipeline while preserving SQLite FTS5/BM25
+  keyword search and the `code_*` codemap tools.
+- CI and release validation are fail-closed; `doctor` checks and the V2-only
+  sandbox validator cover the OpenCode 2 installation path.
 
-## OpenCode V1/V2 — Dual Version (1.5.0-beta.2)
+## OpenCode V1/V2 — Dual Version (1.6.0-beta.1)
 
-Pantheon has two **exclusive** OpenCode plugin contracts. Ordinary OpenCode
+This is the first beta compatible with OpenCode 2. Pantheon has two **exclusive** OpenCode
+plugin contracts. Ordinary OpenCode
 configuration may be shared, but the Pantheon plugin registration is selected
 per installation; V1 and V2 Pantheon plugins must never be registered together.
 
@@ -189,8 +193,9 @@ The V2 plugin provides 6 orchestration tools (`hashline_edit`,
 `pantheon_goal_create`, `pantheon_goal_get`, `pantheon_goal_update`,
 `pantheon_cost`, `pantheon_model`), 4 event subscriptions (`session.created`,
 `session.idle`, `session.error`, `session.compacted`), session hooks (`prompt`,
-`context`), and tool hooks (`execute.before`, `execute.after`). The only
-unsupported V2 feature is `legacy-hooks` (the V1-specific hook surface).
+`context`), and tool hooks (`execute.before`, `execute.after`). Unsupported V2
+features are `legacy-hooks` (the V1-specific hook surface), `catalog-transform`,
+`integration-transform`, and `skill-transform`.
 
 The package exposes both contracts as importable exports: `pantheon-opencode/plugin`
 (V1), `pantheon-opencode/plugin-v2` (V2) and `pantheon-opencode/v2-bridge`
@@ -229,6 +234,29 @@ The installer still writes the compatibility settings required by the selected
 OpenCode host, such as `experimental.subagent_depth`; this does not convert a
 V1 plugin into V2 or provide V2 with V1 hooks.
 
+Pantheon does not set a step ceiling on agents. On OpenCode 2 the `steps`
+field is optional and has no default: absent means the host applies no native
+limit. A config written before this change still carries the old value, and the
+V2 install path strips it from every agent Pantheon manages — an agent you
+define yourself is never touched, and the retiring V1 singular `agent` block
+is left alone. Run the installer once to clear a stale value from an existing
+config:
+
+```bash
+npx pantheon-opencode init --opencode-version=v2
+```
+
+Context control is not a Pantheon setting. Whatever budget an agent runs
+against comes from the compaction settings of the OpenCode host you are
+running, and Pantheon does not define them.
+
+When a V1 `agent` block and a V2 `agents` block are both present — which is
+what an installed `opencode.json` carries — the V1→V2 conversion merges them
+instead of letting one replace the other. The V2 block is the base, the
+framework-managed fields from the V1 block overwrite, and your own fields are
+preserved, matching the precedence the installer already applies elsewhere.
+Key order does not matter.
+
 ## Updating between releases (beta.5+)
 
 One command keeps an existing installation current:
@@ -321,38 +349,66 @@ Release validation keeps each manifest with its lockfile: the root
 SHA-256 of that same artifact, and binds the tarball and GitHub release to the
 full `TARGET_SHA`; a second pack is not interchangeable.
 
-## Sandbox validation (V1/V2)
+## Sandbox validation (V2)
 
-`scripts/test-opencode-v1-v2-sandbox.sh` validates the globally installed
+`scripts/test-opencode-v2-sandbox.sh` validates the globally installed
 package as a real user inside an isolated sandbox (own `HOME`, npm prefix and
-venv) — never the dev environment. It checks OpenCode V1 (`opencode`) and V2
-(`opencode2`) side by side: binaries, MCP connectivity, `doctor`, and — with
-`--prompts` — a prompt battery covering the `pantheon://agents` resource,
-memory store/recall, filesystem writes and agent delegation. The gate is
-fail-closed: every required check must return an explicit PASS; timeouts,
-auth/network/provider failures and missing prerequisites block the run.
+venv) — never the dev environment. It checks the OpenCode V2 leg: the binary,
+MCP connectivity, `doctor`, and — with `--prompts` — a prompt battery covering
+the `pantheon://agents` resource, memory store/recall, filesystem writes and
+agent delegation. The gate is fail-closed: every required check must return an
+explicit PASS; timeouts, auth/network/provider failures and missing
+prerequisites block the run.
+
+"V2" here refers only to the hook canary observed against an OpenCode v2.0.18
+host, where at least one tested hook callback fired; it does not establish
+compatibility with the stable `@opencode/plugin@2.0.18` SDK or full 2.x
+contract. This branch still pins transitional `@opencode-ai/plugin@1.18.30`.
+On hosts where both `opencode` and `opencode2` exist, the latter is typically
+a shim that execs the same binary, so an older side-by-side comparison proved
+nothing about the binary itself. The project is V2-exclusive, so there is a
+single leg.
 
 ```bash
-scripts/test-opencode-v1-v2-sandbox.sh --prepare          # tarball + install + init in the sandbox
-scripts/test-opencode-v1-v2-sandbox.sh --run v1 --prompts # base validation + prompt battery (V1)
-scripts/test-opencode-v1-v2-sandbox.sh --run v2           # base validation only (V2)
-scripts/test-opencode-v1-v2-sandbox.sh --prompts          # prompt battery for both versions
-scripts/test-opencode-v1-v2-sandbox.sh --reset            # wipe the sandbox root
+scripts/test-opencode-v2-sandbox.sh --prepare     # tarball + install + init in the sandbox
+scripts/test-opencode-v2-sandbox.sh --run v2      # base validation only
+scripts/test-opencode-v2-sandbox.sh --prompts     # base validation + prompt battery
+scripts/test-opencode-v2-sandbox.sh --rehydrate   # offline context rehydration/session-summary probe
+scripts/test-opencode-v2-sandbox.sh --hooks       # V2 hook callback canary
+scripts/test-opencode-v2-sandbox.sh --rehydrate --hooks # run both canaries
+scripts/test-opencode-v2-sandbox.sh --reset       # wipe the sandbox root
 ```
 
-Modes are combinable (e.g. `--prepare --run v1 --prompts`). Binaries are
-resolved strictly inside the sandbox npm prefix — a non-prepared sandbox fails
-fast instead of silently testing the host installation.
+Modes are combinable (e.g. `--prepare --run v2 --prompts`). `--rehydrate` runs
+offline `context_rehydrate` and `context_session_summary` probes. `--hooks` runs
+a V2 hook canary against the sandbox binary to check that hook callbacks fire;
+it does not test transform callback effects or prove Pantheon's
+`execute.before` security enforcement. With the probe-only `--rehydrate --hooks`
+pair (without `--run`, `--prompts`, or `--cost`), the hooks canary still runs if
+rehydration fails, and the command returns a failing status afterward. These
+are test/sandbox canaries, not proof of Pantheon security enforcement. Binaries
+are resolved strictly inside the sandbox npm prefix — a non-prepared sandbox
+fails fast instead of silently testing the host installation. The sandbox is
+always built from the checkout this script lives in; it never infers a
+repository from a sibling directory.
 
 This validates the prepared isolated sandbox only. A PASS is not proof of
 support for every real host or for host configurations that were not exercised.
 
+## Plugin V2 TypeScript coverage
+
+`npm run coverage:plugin-v2` runs the `tests/pantheon/*.test.ts` suite with
+Node's source-mapped native coverage and enforces an 80% line-coverage minimum
+for `src/plugin-v2.ts` only. It requires Node `v24.15.0`; branch and function
+coverage are reported but are not gates. This is not a repository-wide coverage
+claim.
+
 Env overrides:
 
 | Variable | Default | Purpose |
 |----------|---------|---------|
 | `PANTHEON_SANDBOX_ROOT` | `~/pantheon-sandbox` | Sandbox root (refused if unsafe for `--reset`) |
-| `OPENCODE_V1_SPEC` | `opencode-ai@1.18.18` | npm spec providing the `opencode` binary |
+| `OPENCODE_V1_SPEC` | `opencode-ai@1.18.18` | Configures the V1 plugin only; the V2-only sandbox runner does not consume or support it |
 | `OPENCODE_V2_SPEC` | `@opencode-ai/cli@beta` | npm spec providing the `opencode2` binary |
 | `PANTHEON_SANDBOX_MODEL` | `opencode-go/mimo-v2.5` | Model used by init and prompts |
 | `PANTHEON_PROMPT_TIMEOUT` | `300` | Per-prompt timeout in seconds |
@@ -382,18 +438,22 @@ and returns nothing. Prefer `background=true` dispatches with an explicit
 
 ## Configuration (environment variables)
 
-| Variable | Default | Description |
-|---|---|---|
-| `PANTHEON_MEMORY_EMBED` | `on` | `off` (also `0`, `false`, `no`) disables the `pantheon-memory` embedding/vector pipeline — search runs in FTS5-only mode with no model download and no `sqlite-vec` writes. Also forced `off` automatically when `fastembed` fails to import, so a broken embedding install never takes the server down (issue #159). |
-
-The memory MCP degrades gracefully: when `fastembed` or `sqlite-vec` are
-unavailable (network failure, incompatible wheel), the server still starts,
-answers the MCP `initialize` handshake, and serves keyword search — only the
-semantic vector ranking is unavailable.
+The `pantheon-memory` MCP server needs no configuration: search is SQLite FTS5
+(BM25) only, all stdlib, with no embedding model, no vector index, and no
+`sqlite-vec`/`fastembed` dependency. Other environment variables are documented
+in the sections above.
 
 
 ## Documentation
 
+### Local evaluations
+
+Promptfoo/evaluation experiments are local-only: place them under
+`evals/promptfoo/`, which is gitignored and excluded from npm packaging,
+package evidence, CI tests, coverage, and release gates. Publish reviewed
+findings as documentation, not the local harness, datasets, outputs, or
+credentials.
+
 - [Installation](docs/INSTALLATION.md) · [Quick start](docs/QUICKSTART.md)
 - [Architecture](docs/ARCHITECTURE.md) · [MCP tools](docs/mcp-tools.md)
 - [Platforms](docs/PLATFORMS.md) · [Upgrading](docs/UPGRADING.md)
@@ -409,10 +469,10 @@ or pull request.
 
 ## Citation and DOI
 
-Pantheon is released under the [MIT License](LICENSE). For the historical
-published v1.4.3 record only, use the [Zenodo DOI](https://doi.org/10.5281/zenodo.22306637);
-it is not the current operational version. Citation metadata is also available
-in [CITATION.cff](CITATION.cff).
+Pantheon is released under the [MIT License](LICENSE). Cite the
+[Zenodo concept DOI](https://doi.org/10.5281/zenodo.22650136), which always
+resolves to the latest archived release; each release also has its own version
+DOI. Citation metadata is also available in [CITATION.cff](CITATION.cff).
 
 Canonical repository: <https://github.com/ils15/pantheon-opencode>
 

package/README.pt-BR.md

@@ -10,7 +10,7 @@ e equipes que querem mais estrutura sem perder o controle do próprio código.
 
 [![Versão](https://img.shields.io/github/v/release/ils15/pantheon-opencode?label=versão)](https://github.com/ils15/pantheon-opencode/releases/latest)
 [![CI](https://img.shields.io/github/actions/workflow/status/ils15/pantheon-opencode/ci.yml?branch=main&label=CI)](https://github.com/ils15/pantheon-opencode/actions)
-[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.22306637.svg)](https://doi.org/10.5281/zenodo.22306637)
+[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.22650136.svg)](https://doi.org/10.5281/zenodo.22650136)
 
 ## O que é?
 
@@ -31,7 +31,7 @@ de planejar o trabalho, avançar, conferir resultados e preservar o contexto
 
 ## Comece em 2 minutos
 
-Requisitos: [OpenCode 1.18.4+](https://opencode.ai/docs/) e Node.js 22+.
+Requisitos: [OpenCode 1.18.4+](https://opencode.ai/docs/) e Node.js `^22.22.2 || ^24.15.0 || >=26.0.0`.
 
 No projeto em que você quer usar o Pantheon:
 
@@ -71,8 +71,8 @@ verificações repetíveis e passagens claras entre etapas do trabalho.
 
 ## Status
 
-Versão operacional neste checkout: **v1.5.0-beta.2** (candidata; esta página
-não afirma publicação). O Pantheon foi feito para OpenCode e depende da
+Versão operacional neste checkout: **v1.6.0-beta.1** (primeira beta compatível
+com OpenCode 2; esta página não afirma publicação). O Pantheon foi feito para OpenCode e depende da
 disponibilidade e da configuração do OpenCode e dos serviços opcionais que você
 escolher. Veja as [releases](https://github.com/ils15/pantheon-opencode/releases)
 e o [changelog](CHANGELOG.md) para acompanhar as mudanças publicadas.
@@ -103,25 +103,17 @@ falha fechado, sem fallback silencioso. O `doctor` valida o manifest e o
 SHA-256 de cada script sem regenerá-lo.
 
 
-## Novidades da 1.5.0-beta.2
+## Novidades da 1.6.0-beta.1
 
-- Instalador exclusivo para OpenCode: guias de plataformas consolidados em um
-  único [guia OpenCode](docs/platforms/opencode.md).
-- Novo CLI `uninstall` com escopos project/global e checagem de ownership:
-  `node scripts/uninstall.mjs --project|--global [--dry-run] [--force]`.
-- Recursos MCP endurecidos: correção do `pantheon://agents` e proteção contra
-  symlink/traversal nos caminhos de recursos.
-- Compatibilidade com OpenCode V2: merge de configuração `plugins` /
-  `mcp.servers.enabled` e launch stdio MCP com PWD correto.
-- `doctor` e health checks de instalação expandidos.
-- Validador de sandbox para instalações globais
-  (`scripts/test-opencode-v1-v2-sandbox.sh`) cobrindo OpenCode V1/V2 lado a
-  lado — veja [Validação em sandbox](#validação-em-sandbox-v1v2).
-- A flag `--prompts` do instalador está planejada para uma release futura.
+- Primeira beta compatível com o contrato de plugin do OpenCode 2.
+- Remoção do pipeline legado de vector-memory, preservando a busca por palavras-
+  chave SQLite FTS5/BM25 e as ferramentas de codemap `code_*`.
+- Validações de CI e release fail-closed; `doctor` e o sandbox exclusivo V2
+  cobrem o caminho de instalação do OpenCode 2.
 
-## OpenCode V1/V2 — Versão dupla (1.5.0-beta.2)
+## OpenCode V1/V2 — Versão dupla (1.6.0-beta.1)
 
-O Pantheon tem dois contratos de plugin OpenCode **exclusivos**. A configuração
+Esta é a primeira beta compatível com o OpenCode 2. O Pantheon tem dois contratos de plugin OpenCode **exclusivos**. A configuração
 comum do OpenCode pode ser compartilhada, mas o registro do plugin Pantheon é
 selecionado por instalação; os plugins Pantheon V1 e V2 nunca devem ser
 registrados juntos.
@@ -137,8 +129,9 @@ O plugin V2 fornece 6 ferramentas de orquestração (`hashline_edit`,
 `pantheon_goal_create`, `pantheon_goal_get`, `pantheon_goal_update`,
 `pantheon_cost`, `pantheon_model`), 4 assinaturas de eventos (`session.created`,
 `session.idle`, `session.error`, `session.compacted`), session hooks (`prompt`,
-`context`) e tool hooks (`execute.before`, `execute.after`). O único recurso V2
-sem suporte é `legacy-hooks` (a superfície de hooks específica do V1).
+`context`) e tool hooks (`execute.before`, `execute.after`). Os recursos V2 sem
+suporte são `legacy-hooks` (a superfície de hooks específica do V1),
+`catalog-transform`, `integration-transform` e `skill-transform`.
 
 O pacote expõe os dois contratos como exports importáveis:
 `pantheon-opencode/plugin` (V1), `pantheon-opencode/plugin-v2` (V2) e
@@ -178,6 +171,29 @@ O instalador continua gravando as configurações de compatibilidade exigidas
 pelo host OpenCode selecionado, como `experimental.subagent_depth`; isso não
 converte um plugin V1 em V2 nem dá hooks V1 ao V2.
 
+O Pantheon não define mais um teto de passos para os agentes. No OpenCode 2 o
+campo `steps` é opcional e não tem default: ausente significa que o host não
+aplica nenhum limite nativo. Uma config escrita antes dessa mudança ainda
+carrega o valor antigo, e o caminho de instalação v2 o remove de todos os
+agentes que o Pantheon gerencia — um agente definido por você nunca é tocado,
+e o bloco V1 singular `agent`, em retirada, é deixado intacto. Rode o
+instalador uma vez para limpar um valor antigo de uma config existente:
+
+```bash
+npx pantheon-opencode init --opencode-version=v2
+```
+
+O controle de contexto não é uma configuração do Pantheon. Qualquer orçamento
+que um agente terá vem das settings de compactação do próprio host OpenCode,
+e o Pantheon não as define.
+
+Quando um bloco V1 `agent` e um bloco V2 `agents` coexistem — o que acontece
+em qualquer `opencode.json` já instalado — a conversão V1→V2 mescla os dois em
+vez de deixar um substituir o outro. O bloco V2 é a base, os campos
+gerenciados que vêm do V1 sobrescrevem, e os seus próprios campos são
+preservados, com a mesma precedência que o instalador já aplica em outros
+pontos. A ordem das chaves não muda o resultado.
+
 ## Atualizando entre releases (beta.5+)
 
 Um comando mantém uma instalação existente em dia:
@@ -228,39 +244,66 @@ fallback para `npm install`. Uma release carrega um único tarball `.tgz`, calcu
 o SHA-256 desse mesmo artefato e vincula o tarball e o GitHub Release ao
 `TARGET_SHA` completo; um segundo pack não é intercambiável.
 
-## Validação em sandbox (V1/V2)
+## Validação em sandbox (V2)
 
-O `scripts/test-opencode-v1-v2-sandbox.sh` valida o pacote instalado
+O `scripts/test-opencode-v2-sandbox.sh` valida o pacote instalado
 globalmente como um usuário real dentro de um sandbox isolado (com `HOME`,
 prefix npm e venv próprios) — nunca o ambiente de desenvolvimento. Ele verifica
-OpenCode V1 (`opencode`) e V2 (`opencode2`) lado a lado: binários, conectividade
-MCP, `doctor` e — com `--prompts` — uma bateria de prompts cobrindo o recurso
-`pantheon://agents`, memory store/recall, escrita no filesystem e delegação de
-agente. O gate é fail-closed: todo check obrigatório precisa terminar em PASS
-explícito; timeout, falha de auth/rede/provider e pré-requisitos ausentes
-bloqueiam a execução.
+a perna OpenCode V2: o binário, conectividade MCP, `doctor` e — com
+`--prompts` — uma bateria de prompts cobrindo o recurso `pantheon://agents`,
+memory store/recall, escrita no filesystem e delegação de agente. O gate é
+fail-closed: todo check obrigatório precisa terminar em PASS explícito;
+timeout, falha de auth/rede/provider e pré-requisitos ausentes bloqueiam a
+execução.
+
+"V2" aqui se refere somente ao canário de hooks observado em um host OpenCode
+v2.0.18, no qual ao menos um callback testado foi disparado; isso não
+estabelece compatibilidade com o SDK estável `@opencode/plugin@2.0.18` nem com
+o contrato 2.x completo. Esta branch ainda fixa a dependência transitória
+`@opencode-ai/plugin@1.18.30`. Em hosts com `opencode` e `opencode2`, este
+último costuma ser um shim que executa o mesmo binário; a comparação lado a
+lado anterior, portanto, não provava nada sobre o binário em si. O projeto é
+exclusivo V2, portanto há uma única perna.
 
 ```bash
-scripts/test-opencode-v1-v2-sandbox.sh --prepare          # tarball + install + init no sandbox
-scripts/test-opencode-v1-v2-sandbox.sh --run v1 --prompts # validação base + bateria de prompts (V1)
-scripts/test-opencode-v1-v2-sandbox.sh --run v2           # apenas validação base (V2)
-scripts/test-opencode-v1-v2-sandbox.sh --prompts          # bateria de prompts para as duas versões
-scripts/test-opencode-v1-v2-sandbox.sh --reset            # limpa a raiz do sandbox
+scripts/test-opencode-v2-sandbox.sh --prepare     # tarball + install + init no sandbox
+scripts/test-opencode-v2-sandbox.sh --run v2      # apenas validação base
+scripts/test-opencode-v2-sandbox.sh --prompts     # validação base + bateria de prompts
+scripts/test-opencode-v2-sandbox.sh --rehydrate   # sondas offline de rehydration/summary de sessão
+scripts/test-opencode-v2-sandbox.sh --hooks       # canário de callbacks de hooks V2
+scripts/test-opencode-v2-sandbox.sh --rehydrate --hooks # executa os dois canários
+scripts/test-opencode-v2-sandbox.sh --reset       # limpa a raiz do sandbox
 ```
 
-Os modos são combináveis (ex.: `--prepare --run v1 --prompts`). Os binários são
-resolvidos estritamente dentro do prefix npm do sandbox — um sandbox não
-preparado falha rápido em vez de testar silenciosamente a instalação do host.
+Os modos são combináveis (ex.: `--prepare --run v2 --prompts`). `--rehydrate`
+executa sondas offline de `context_rehydrate` e `context_session_summary`.
+`--hooks` executa um canário de hooks V2 com o binário do sandbox para verificar
+se os callbacks de hooks são disparados; ele não testa os efeitos dos callbacks
+de transform nem comprova o enforcement de segurança `execute.before` do
+Pantheon. Com o par de sondas `--rehydrate --hooks` (sem `--run`, `--prompts` ou
+`--cost`), o canário de hooks ainda é executado se a rehydration falhar, e o
+comando retorna falha em seguida. Esses canários de teste/sandbox não são prova
+de enforcement de segurança do Pantheon. Os binários são resolvidos estritamente
+dentro do prefix npm do sandbox — um sandbox não preparado falha rápido em vez
+de testar silenciosamente a instalação do host.
 
 Isso valida somente o sandbox isolado e preparado. Um PASS não prova suporte
 para todo host real nem para configurações de host que não foram exercitadas.
 
+## Cobertura TypeScript do Plugin V2
+
+`npm run coverage:plugin-v2` executa a suíte `tests/pantheon/*.test.ts` com a
+cobertura nativa do Node habilitada para source maps e exige pelo menos 80% de
+cobertura de linhas somente para `src/plugin-v2.ts`. Requer Node `v24.15.0`;
+coberturas de branches e funções são informativas, não gates. Isso não é uma
+alegação de cobertura do repositório inteiro.
+
 Variáveis de ambiente:
 
 | Variável | Padrão | Finalidade |
 |----------|---------|---------|
 | `PANTHEON_SANDBOX_ROOT` | `~/pantheon-sandbox` | Raiz do sandbox (recusada se insegura para `--reset`) |
-| `OPENCODE_V1_SPEC` | `opencode-ai@1.18.18` | Spec npm que fornece o binário `opencode` |
+| `OPENCODE_V1_SPEC` | `opencode-ai@1.18.18` | Configura somente o plugin V1; o runner de sandbox exclusivo V2 não consome nem oferece suporte a essa variável |
 | `OPENCODE_V2_SPEC` | `@opencode-ai/cli@beta` | Spec npm que fornece o binário `opencode2` |
 | `PANTHEON_SANDBOX_MODEL` | `opencode-go/mimo-v2.5` | Modelo usado pelo init e pelos prompts |
 | `PANTHEON_PROMPT_TIMEOUT` | `300` | Timeout por prompt em segundos |
@@ -295,10 +338,10 @@ uma issue ou pull request.
 
 ## Citação e DOI
 
-O Pantheon é distribuído sob a [Licença MIT](LICENSE). Para o registro histórico
-publicado da v1.4.3 apenas, use o [DOI do Zenodo](https://doi.org/10.5281/zenodo.22306637);
-essa não é a versão operacional atual. Os metadados de citação também estão em
-[CITATION.cff](CITATION.cff).
+O Pantheon é distribuído sob a [Licença MIT](LICENSE). Cite o
+[DOI conceitual do Zenodo](https://doi.org/10.5281/zenodo.22650136), que sempre
+resolve para a última release arquivada; cada release também tem seu próprio
+version DOI. Os metadados de citação também estão em [CITATION.cff](CITATION.cff).
 
 Repositório canônico: <https://github.com/ils15/pantheon-opencode>
 

package/commands/pantheon-optimize.md

@@ -4,7 +4,7 @@ agent: "zeus"
 ---
 # /pantheon-optimize — Pantheon Project Optimizer
 
-**What:** Multi-mode optimization: scans for documentation bloat, archives completed deepwork, migrates memory-bank flat files to MCP memory (ChromaDB), and reports token savings.
+**What:** Multi-mode optimization: scans for documentation bloat, archives completed deepwork, migrates memory-bank flat files to the FTS5-backed MCP memory server, and reports token savings.
 
 ## Usage
 
@@ -33,7 +33,7 @@ Archives completed deepwork sessions from `.pantheon/deepwork/<slug>/` to `.pant
 ```
 
 ### `--cache` — Memory Bank Migration
-Scans `.pantheon/memory-bank/` for flat `.md` files and migrates them to the MCP memory server (ChromaDB).
+Scans `.pantheon/memory-bank/` for flat `.md` files and migrates them to the FTS5-backed MCP memory server.
 
 **What it does:**
 1. Reads all `.md` files in `.pantheon/memory-bank/`

package/package.json

@@ -1,8 +1,11 @@
 {
   "name": "pantheon-opencode",
-  "version": "1.5.2",
+  "version": "1.6.0-beta.2",
   "description": "Multi-agent orchestration for OpenCode — 14 specialized agents, TDD, Themis review gates.",
   "type": "module",
+  "workspaces": [
+    "src/plugins/tui"
+  ],
   "publishConfig": {
     "access": "public",
     "registry": "https://registry.npmjs.org/"
@@ -39,7 +42,10 @@
     "hooks:update": "pre-commit autoupdate",
     "test:security": "npm run secret-scan",
     "test:node": "node --test tests/*.mjs tests/pantheon/*.mjs",
+    "coverage": "echo 'Node coverage (report-only, NO threshold is enforced).' && echo 'Covers: the .mjs/.js modules under scripts/, src/ and bin/ that test:node exercises.' && echo 'Does NOT cover: test:ts (hand-rolled tsx loop, no node --test runner) and test:ci (pytest).' && echo '             TypeScript under src/ (41 files) is therefore entirely unmeasured here.' && echo '' && node --test --experimental-test-coverage --test-coverage-include='scripts/**/*.mjs' --test-coverage-include='src/**/*.mjs' --test-coverage-include='src/**/*.js' --test-coverage-include='bin/**/*.mjs' tests/*.mjs tests/pantheon/*.mjs",
+    "coverage:plugin-v2": "node scripts/check-plugin-v2-coverage.mjs",
     "test:ts": "for f in tests/pantheon/*.test.ts; do if [ \"$f\" = tests/pantheon/plugin-v2-contract.test.ts ]; then NODE_OPTIONS=--conditions=import tsx \"$f\"; else tsx \"$f\"; fi || exit 1; done",
+    "test:hooks": "node --test tests/pantheon/plugin-v2-hook-canary.test.mjs",
     "test:all": "npm run test:ci && npm run test:node && npm run test:ts",
     "test": "npm run test:all",
     "test:ci": "python3 -m pytest -q --tb=short 2>&1"
@@ -78,6 +84,9 @@
     "src/routing.yml",
     "src/pantheon/**",
     ".pantheon/code-mode/**",
+    "!.pantheon/code-mode/session-end-save.py",
+    "!.pantheon/code-mode/session-end-save.sh",
+    "!.pantheon/code-mode/eval-*.py",
     "src/plugins/**",
     "scripts/hooks/**",
     "src/mcp/requirements*",
@@ -100,6 +109,9 @@
     "tsx": "4.23.13",
     "typescript": "6.0.3"
   },
+  "overrides": {
+    "rolldown": "1.2.0"
+  },
   "repository": {
     "type": "git",
     "url": "https://github.com/ils15/pantheon-opencode.git"

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "pantheon",
   "publisher": "ils15",
-  "version": "1.5.2",
+  "version": "1.6.0-beta.2",
   "displayName": "Pantheon",
   "description": "Conductor-Delegate orchestration platform with 14 specialized agents, 21 skills, and OpenCode support.",
   "agents": "./src/agents",

package/pyproject.toml

@@ -4,19 +4,17 @@ build-backend = "setuptools.backends._legacy:_Backend"
 
 [project]
 name = "pantheon"
-version = "1.5.2"
+version = "1.6.0-beta.2"
 description = "Multi-agent orchestration framework"
 requires-python = ">=3.11"
 dependencies = []
 
 [tool.pytest.ini_options]
-# `tests/` holds the main suite; the two entries below are orphaned test
-# modules that live next to the code they cover and are collected here so
-# pytest (and therefore `npm test`) exercises them instead of letting them
-# rot as dead code.
+# `tests/` holds the main suite; the entry below is an orphaned test module
+# that lives next to the code it covers and is collected here so pytest (and
+# therefore `npm test`) exercises it instead of letting it rot as dead code.
 testpaths = [
     "tests",
-    "scripts/vector_memory/test_memory.py",
     "benchmarks/beta2/test_beta2.py",
 ]
 asyncio_mode = "auto"
@@ -28,7 +26,6 @@ target-version = "py311"
 
 [tool.ruff.lint]
 select = ["E", "F", "W", "I", "N", "UP", "B", "SIM", "PL", "RUF", "C901"]
-ignore = ["E501"]
 
 [tool.ruff.lint.per-file-ignores]
 "__init__.py" = ["F401"]
@@ -36,21 +33,17 @@ ignore = ["E501"]
 "scripts/ci-validate-yaml.py" = ["N999"]
 "scripts/scrub-secrets.py" = ["N999"]
 # These modules defer optional/heavy imports until the corresponding command is used.
-"scripts/vector_memory/*.py" = ["PLC0415"]
 "tests/test_code_mode_sandbox.py" = ["PLC0415", "N806"]
 "tests/test_code_mode_server.py" = ["PLC0415"]
 "tests/test_codemap_mcp.py" = ["PLC0415"]
 "tests/test_memory_mcp_server.py" = ["PLC0415", "PLR2004"]
 # Existing public APIs and test fixtures are intentionally broad/simple; refactoring
 # them would be behavior-affecting rather than a mechanical lint correction.
-"scripts/code_mode_server.py" = ["PLR0913"]
-"src/mcp/code_mode_server.py" = ["PLR0913"]
-"scripts/mcp_persistence_server.py" = ["PLR0913"]
-"src/mcp/mcp_persistence_server.py" = ["PLR0913"]
+"scripts/code_mode_server.py" = ["PLR0913", "PLR0917"]
+"src/mcp/code_mode_server.py" = ["PLR0913", "PLR0917"]
+"scripts/mcp_persistence_server.py" = ["PLR0913", "PLR0917"]
+"src/mcp/mcp_persistence_server.py" = ["PLR0913", "PLR0917"]
 "scripts/memory_mcp_server.py" = ["C901"]
-"scripts/vector_memory/index.py" = ["C901", "PLR0913", "PLR2004", "PLW0603", "PLW2901"]
-"scripts/vector_memory/cli.py" = ["PLR2004"]
-"scripts/vector_memory/query.py" = ["PLR0913"]
 "src/mcp/eval_store.py" = ["PLR2004"]
 "tests/test_code_mode_frontmatter.py" = ["PLR2004"]
 "tests/test_eval.py" = ["PLR2004"]

package/scripts/build-agents-md.mjs

@@ -106,7 +106,7 @@ function parseInstruction(content) {
   if (!nameMatch) return null
   return {
     name: nameMatch[1].trim(),
-    body: content.slice(match[0].length).trimEnd() + '\n',
+    body: `${content.slice(match[0].length).trimEnd()}\n`,
   }
 }
 
@@ -165,7 +165,7 @@ export function generateAgentsMd(instructions) {
       '',
     )
   }
-  return sections.join('\n').trimEnd() + '\n'
+  return `${sections.join('\n').trimEnd()}\n`
 }
 
 // ---------------------------------------------------------------------------