pantheon-opencode 1.6.0-beta.2 → 1.6.0-beta.4

package/CHANGELOG.md

@@ -18,6 +18,118 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## ✅ Closed Issues
 
+## [v1.6.0-beta.4] - 2026-10-03
+
+<!-- Add new changes here. Running `node scripts/versioning.mjs apply` will
+     move this section to a versioned entry and reset the template below. -->
+
+## 🆕 What's New
+
+- **Canário host-backed que dirige `hashline_edit` end-to-end** (`tests/canary/plugin-v2-tool-canary.test.mjs`, 12 casos): carrega `src/plugin-v2.ts` pelo loader real do host `opencode 2.0.22` e registra `Object.keys(ctx)` de dentro do host — medidos, `tool`/`event`/`permission`/`session` existem e `catalog` não. É o primeiro gate que dirige uma ferramenta do Pantheon por um host real. O canário existente só dirige o `read` embutido, e foi por isso que `draft.add()` sem `output` sobreviveu 26 dias com todos os testes verdes.
+- **Os quatro domínios que o SDK `@opencode-ai/plugin` não tipa** (`tool`, `event`, `permission`, `session`) passaram a uma declaração estrutural local (`HostPluginContext`) e **um** cast documentado (`hostDomains()`), no lugar de seis `as unknown as Record<string, unknown>` que não verificavam tipo nenhum. Todo membro continua opcional e todo chamador reconferir antes de usar. A linha estável do SDK é `1.18.x` e não carrega o contrato do host — `1.18.34` (`latest`) é idêntica a `1.18.33`, então seguir o `dev` diário resolveria pior, não melhor.
+
+## 🐞 Fixed
+
+- `pantheon_cost` respondia `CORRUPT_DATA` em **toda** chamada contra o host 2.0.22: exigia a tabela `message`, que não existe nesse banco. Os tokens de assistant **estão** legíveis em `session_message`. **Não é renomeação:** `session_message` tem coluna `data`, mas não tem a chave `role` dentro dela — `json_type(data,'$.role')` é nulo em **0 de 40 307** linhas válidas. O V1 marca turnos de assistant com `data.role`; o V2 marca pela **coluna** `type`. Trocar apenas o nome da tabela casaria com nada e devolveria `status: OK` em silêncio. A detecção passa a ser por **presença de tabela**, porque as duas famílias coexistem em bancos migrados.
+- `PANTHEON_OPENCODE_VERSION` nunca selecionou o schema: só mudava o **nome do arquivo**, e `opencode-v2.db` é o isolamento do sandbox via `OPENCODE_DB`, não um banco de host 2.x. A distinção v1/v2 é o **schema detectado**; a variável agora apenas restringe um conjunto já detectado e falha rápido quando pede uma família ausente.
+- `scripts/cost.mjs` duplicava o mesmo bug literal, com o mesmo assert — o fallback continuava morto. `probe-pantheon-cost.mjs` acompanha.
+- O report agora **declara a cobertura temporal** que ele mediu (janela varrida, linha mais antiga), em vez de apresentar totais como se cobrissem meses.
+
+## ⚠️ Known Issues
+
+- O canário **host-backed pula no CI**: o runner não tem binário `opencode`. O skip é **visível** no log (`::notice`), e os dois casos sem host rodam incondicionalmente, com `PANTHEON_TOOL_CANARY_BIN` apontado para um caminho inexistente. Rodar de verdade exige um modo no script de sandbox — **não feito**.
+- A cobertura de custo do banco v2 é de **~8,3 dias** nesta máquina (primeiro registro em 2026-09-25). O histórico v1 (~96 dias) fica num diretório irmão com nome de epoch, que **não** é contrato e por isso não é descoberto automaticamente. Quem quiser aponta `PANTHEON_COST_DB`.
+- `metadata.phase` nunca existiu em v1 nem em v2 — medido: 0 linhas de `session_message` têm `$.metadata.phase` nem `$.phase`. A coluna Phase sempre foi `unknown`. Não é regressão, é feature que nunca funcionou.
+## [v1.6.0-beta.3] - 2026-10-03
+
+&lt;!-- Add new changes here. Running `node scripts/versioning.mjs apply` will
+     move this section to a versioned entry and reset the template below. --&gt;
+
+## 🆕 What's New
+- **Três ferramentas V2 agora executam de verdade**: `hashline_edit`,
+  `pantheon_cost` e `pantheon_model` rodam no host `opencode v2.0.x`. Antes
+  eram placeholders que declaravam sucesso sem fazer nada.
+- **Enforcement de sessão read-only no caminho V2**: `apollo` e `gaia` voltam
+  a ter escrita bloqueada, com o guard registrado no próprio plugin V2 — sem
+  depender de uma ponte que a instalação V2 não monta.
+- **Varredura de segredos de alta confiança no caminho V2**: o único hard block
+  de segurança que a V1 tinha, e que estava inerte por viver num plugin que a
+  instalação V2 não carrega, passa a rodar.
+
+## 🐞 Fixed
+- **As 6 ferramentas de plugin do V2 falhavam em 100% das chamadas**:
+  `hashline_edit`, `pantheon_cost` e `pantheon_model` lançavam
+  `Tool result declared output without an output schema` em toda invocação. A
+  causa era assimetria local — `draft.add()` não declarava `output` enquanto o
+  `execute` resolvia `{ output: string }`. O host exige simetria nos dois
+  sentidos: resultado com `output` e nenhuma declaração lança, assim como
+  declaração sem `output` no resultado. `output` passou a ser **obrigatório** na
+  interface `V2ToolDef`, então o compilador exige a declaração daqui em diante.
+- **A suíte exigia o defeito**: `tests/pantheon/plugin-v2-contract.test.ts`
+  afirmava que o resultado carregava `.output` string — literalmente a condição
+  de falha, contra um mock que não reproduzia a exigência do host. O teste foi
+  reescrito para o invariante de simetria, contra um mock que constrói o
+  `outputSchema` a partir de `def.output` como o host faz
+  (`output: I.outputSchema ?? {}`), cobrindo as duas direções do bicondicional.
+- **A imposição read-only não existia na superfície V2**: `createEnforcementGuard`
+  só era instanciado em `src/plugin.ts`, que o `opencode.json` da release não
+  declara — V2 nunca carrega V1. Com `hashline_edit` funcional, uma sessão
+  somente-leitura podia escrever arquivos. O guard passou a ser registrado no
+  hook `execute.before` do V2, e `pantheon_model` — que escreve
+  `active-preset.json` em escopo project e global — foi acrescentado a
+  `DEFAULT_BLOCKED_TOOLS`, o que corrige também a V1. `pantheon_cost` ficou de
+  fora de propósito: só lê `opencode.db`.
+- **O único hard block de segurança da V1 estava inerte**: o scan de segredos de
+  alta confiança vivia em `src/plugins/pantheon-hooks.ts`, um plugin que a
+  instalação V2 não carrega — inerte por construção, não por má configuração.
+  Passou a rodar dentro do `execute.before` do V2
+  (`scripts/hooks/scan-secrets.sh`; exit 2 bloqueia, exit 1 é advisory e só
+  registra). O caminho do script foi verificado a partir do tarball instalado,
+  não só do repo.
+- **Cinco comentários afirmavam cobertura que não existe** ("wired through the
+  V1…"). Corrigidos — é o defeito "anunciado como vivo, morto no caminho", a
+  mesma classe do bug original, transferida do tool para o controle de segurança.
+
+## ⚠️ Known Issues
+- **A release entrega 3 ferramentas V2 funcionais, não 6**:
+  `pantheon_goal_create`, `pantheon_goal_get` e `pantheon_goal_update` foram
+  **removidos** da superfície V2. `GoalLoopDeps` exige `store`, `client` e
+  `board`, que não existem no `PluginContext` V2, e a bridge V1 resolve para
+  `null` fora da V1. Registrá-las como placeholders não funcionais seria pior
+  que a ausência: anunciá-las seria mentira silenciosa. Marcador `goal-tools`
+  em `V2_UNSUPPORTED_FEATURES`. **Breaking** para quem usava esses tools no
+  host V2 — o contrato V1 permanece disponível para o goal loop.
+- **A matriz de delegação nativa da V1 não é replicada na V2**: o guard V2 cobre
+  a lista de ferramentas bloqueadas, mas não a matriz caller→target nem a negação
+  de `task` em sessão filha. A matriz precisa de uma hierarquia de sessões
+  semeada a partir dos metadados de sessão, e o V2 não expõe esse caminho de
+  semeadura — `SessionHierarchyRegistry.isRoot` reporta `true` para sessões
+  desconhecidas enquanto não semeada, então semeá-la pela metade negaria todo
+  `task()`. O branch é pulado em vez de negado indiscriminadamente. Marcador
+  `delegation-matrix`. `task` continua negada em sessão somente-leitura pela
+  lista de ferramentas bloqueadas, então a profundidade 2 se sustenta; o que
+  não existe é a matriz. Coberto por `experimental.subagent_depth` nesta
+  configuração, mas a garantia do plugin não existe.
+- **O log do scan de segredos escreve só em `.pantheon/logs/hooks.log`**: o
+  `PluginContext` V2 não expõe `client` nem `directory`, então os canais de log
+  estruturado e de toast da V1 não existem nessa superfície. É menos
+  observabilidade, não menos bloqueio.
+- **Falha de infraestrutura do scanner é fail-open por decisão**: script ausente
+  ou timeout não bloqueiam. `runHook` nunca rejeita e um erro de infraestrutura
+  não deve negar chamadas não relacionadas. Ausência do script não bloqueia.
+
+## ✅ Closed Issues
+- **Drift de documentação no `README.pt-BR.md`**: a tabela de contrato de
+  runtime e o parágrafo de superfície listavam 6 ferramentas V2 e as 3 de goal,
+  que não estão registradas. Corrigido para 3 ferramentas, com a razão da
+  ausência e o ponto de imposição read-only.
+- **Cinco comentários de falsa cobertura** sobre a imposição read-only e o scan
+  de segredos.
+- **Shim do loader JSON do ajv elevado a bootstrap de módulo**: o patch de
+  `Module._extensions['.json']` era aplicado de dentro de `loadAjv()` e ficava
+  vivo durante todo o run, podendo vazar entre arquivos de teste e se manifestar
+  longe da causa. Agora instala, carrega e restaura em nível de módulo, antes de
+  qualquer corpo de teste, com `finally`.
 ## [v1.6.0-beta.2] - 2026-10-02
 
 ## 🆕 What's New

package/README.md

@@ -50,6 +50,8 @@ opencode
 The installer guides you through the available setup. For optional MCP servers,
 project-local installation, or non-interactive setup, see the
 [installation guide](docs/INSTALLATION.md).
+The bundled Python MCP servers use the pinned MCP SDK 2.2.0 and standalone
+FastMCP 4.0.10 runtime; see the [MCP guide](docs/MCP.md).
 
 ## A simple example
 
@@ -186,16 +188,36 @@ per installation; V1 and V2 Pantheon plugins must never be registered together.
 |---|---|---|
 | OpenCode config key | singular `plugin` | plural `plugins` |
 | Pantheon registration | `src/plugin.ts` plus `src/plugins/pantheon-hooks.ts` | `<installed>/src/plugin-v2` directory (`index.ts` re-exports `src/plugin-v2.ts`) |
-| Runtime contract | Pantheon V1 plugin: 6 tools (`hashline_edit`, the 3 goal tools, `pantheon_cost`, `pantheon_model`), event/tool hooks and V1 compaction handling | Full V2 plugin: 6 orchestration tools, 4 event subscriptions, session hooks (`prompt`, `context`), tool hooks (`execute.before`/`after`), plus configuration transforms |
+| Runtime contract | Pantheon V1 plugin: 6 tools (`hashline_edit`, the 3 goal tools, `pantheon_cost`, `pantheon_model`), event/tool hooks and V1 compaction handling | Full V2 plugin: 3 tools (`hashline_edit`, `pantheon_cost`, `pantheon_model`), 4 event subscriptions, session hooks (`prompt`, `context`), a read-only-enforcing tool `execute.before` hook, plus configuration transforms |
 | V1 APIs | Registered | Own tool definitions via `ctx.tool.transform()` — not the V1 plugin path |
 
-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`). Unsupported V2
-features are `legacy-hooks` (the V1-specific hook surface), `catalog-transform`,
-`integration-transform`, and `skill-transform`.
+The V2 plugin provides 3 orchestration tools (`hashline_edit`, `pantheon_cost`,
+`pantheon_model`), 4 event subscriptions (`session.created`, `session.idle`,
+`session.error`, `session.compacted`), session hooks (`prompt`, `context`),
+and a tool `execute.before` hook that enforces read-only sessions. The 3 goal
+tools are **not**
+registered on V2: the goal loop needs a `GoalStore`, a `GoalLoopClient` and a
+`BackgroundJobBoard`, none of which the V2 `PluginContext` exposes, so the gap
+is reported as the `goal-tools` unsupported-feature marker. Use the V1
+contract if you need the goal loop.
+
+The V2 `execute.before` hook is the read-only enforcement point for that
+surface: the host includes the active agent on the event, a read-only agent
+(`apollo`, `gaia`) registers its session, and the shared
+`createEnforcementGuard` throws to deny `edit`, `write`, `bash`, `task`,
+`hashline_edit` and `pantheon_model`. It does **not** rely on the V1
+`tool.execute.before` hook, which lives in `src/plugin.ts` and is not loaded
+when only `plugin-v2` is configured. The companion `execute.after` hook and the
+`permission.evaluate` hook are registration points with no V2-side behaviour,
+and the V1 caller/target delegation matrix for native `task()` is not enforced
+on V2.
+
+Every V2 tool declares an `output` schema. OpenCode 2.0.x requires the
+declaration and the resolved result to agree in both directions, so an
+undeclared tool — or one that returns `output` without declaring it — fails on
+every call. Unsupported V2 features are `legacy-hooks` (the V1-specific hook
+surface), `catalog-transform`, `integration-transform`, `skill-transform` and
+`goal-tools`.
 
 The package exposes both contracts as importable exports: `pantheon-opencode/plugin`
 (V1), `pantheon-opencode/plugin-v2` (V2) and `pantheon-opencode/v2-bridge`
@@ -222,13 +244,23 @@ Pantheon references from both config shapes before writing only the selected
 Pantheon registration. Third-party entries are not converted or claimed by
 this rule.
 
-The V1-only `pantheon_cost` report can select its database with
-`PANTHEON_OPENCODE_VERSION=v1` or `v2` (`opencode.db` or `opencode-v2.db`).
-`PANTHEON_COST_DB=/absolute/path/to/opencode.db` takes precedence over the
-version selector, and an explicit `dbPath` supplied by the tool caller takes
-precedence over both. The resolver never probes the other version's database
-and reports an actionable error when the selected DB is missing or has an
-incompatible schema.
+The `pantheon_cost` report resolves its database by PATH, in this order: an
+explicit `dbPath` supplied by the tool caller, then
+`PANTHEON_COST_DB=/absolute/path/to/opencode.db`, then `OPENCODE_DB`, then the
+XDG default `opencode.db`. There is no per-version filename in that chain:
+`opencode-v2.db` is not a host 2.x database — it is the name a sandbox gives
+its own state database through `OPENCODE_DB`.
+
+The v1/v2 distinction is the DETECTED SCHEMA, not the file name. The report
+looks for the `message` and `session_message` tables and reads whichever the
+open database actually holds, because a migrated database carries both
+families at once. `PANTHEON_OPENCODE_VERSION=v1|v2` selects no file: it only
+narrows an already-detected set to one table family, and fails fast when the
+value is neither `v1` nor `v2` or when the requested family is not there. Left
+unset, every detected family is read. A database carrying neither table comes
+back as an actionable error (`CORRUPT_DATA`), and a ledger that exists but
+yields no readable tokens as `UNSUPPORTED` — never as a successful empty
+report.
 
 The installer still writes the compatibility settings required by the selected
 OpenCode host, such as `experimental.subagent_depth`; this does not convert a

package/README.pt-BR.md

@@ -122,16 +122,36 @@ registrados juntos.
 |---|---|---|
 | Chave de config do OpenCode | `plugin` singular | `plugins` plural |
 | Registro Pantheon | `src/plugin.ts` mais `src/plugins/pantheon-hooks.ts` | `pantheon-opencode/plugin-v2` (`src/plugin-v2.ts`) |
-| Contrato de runtime | Plugin Pantheon V1: 6 ferramentas (`hashline_edit`, as 3 ferramentas de goal, `pantheon_cost`, `pantheon_model`), hooks de evento/ferramenta e tratamento de compactação V1 | Plugin V2 completo: 6 ferramentas de orquestração, 4 assinaturas de eventos, session hooks (`prompt`, `context`), tool hooks (`execute.before`/`after`), além de transforms de configuração |
+| Contrato de runtime | Plugin Pantheon V1: 6 ferramentas (`hashline_edit`, as 3 ferramentas de goal, `pantheon_cost`, `pantheon_model`), hooks de evento/ferramenta e tratamento de compactação V1 | Plugin V2 completo: 3 ferramentas (`hashline_edit`, `pantheon_cost`, `pantheon_model`), 4 assinaturas de eventos, session hooks (`prompt`, `context`), um hook de ferramenta `execute.before` que impõe sessões somente-leitura, além de transforms de configuração |
 | APIs V1 | Registradas | Definições próprias de ferramentas via `ctx.tool.transform()` — não pelo caminho do plugin V1 |
 
-O plugin V2 fornece 6 ferramentas de orquestração (`hashline_edit`,
-`pantheon_goal_create`, `pantheon_goal_get`, `pantheon_goal_update`,
+O plugin V2 fornece 3 ferramentas de orquestração (`hashline_edit`,
 `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`). 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`.
+`context`) e um hook de ferramenta `execute.before` que impõe sessões
+somente-leitura. As 3 ferramentas de goal **não** são
+registradas no V2: o goal loop precisa de um `GoalStore`, de um
+`GoalLoopClient` e de um `BackgroundJobBoard`, nenhum dos quais o
+`PluginContext` do V2 expõe, então a lacuna é reportada como o marcador de
+recurso sem suporte `goal-tools`. Use o contrato V1 se precisar do goal loop.
+
+O hook `execute.before` do V2 é o ponto de imposição de sessões somente-leitura
+dessa superfície: o host inclui o agente ativo no evento, um agente somente-leitura
+(`apollo`, `gaia`) registra sua sessão, e o `createEnforcementGuard`
+compartilhado lança para negar `edit`, `write`, `bash`, `task`,
+`hashline_edit` e `pantheon_model`. Ele **não** depende do hook
+`tool.execute.before` do V1, que vive em `src/plugin.ts` e não é carregado
+quando apenas `plugin-v2` está configurado. Os hooks companheiros
+`execute.after` e `permission.evaluate` são pontos de registro sem comportamento
+do lado V2, e a matriz de delegação caller/target da V1 para o `task()` nativo
+não é imposta no V2.
+
+Toda ferramenta V2 declara um schema `output`. O OpenCode 2.0.x exige que a
+declaração e o resultado resolvido concordem nos dois sentidos, então uma
+ferramenta sem declaração — ou que retorne `output` sem declará-lo — falha em
+toda chamada. Os recursos V2 sem suporte são `legacy-hooks` (a superfície de
+hooks específica do V1), `catalog-transform`, `integration-transform`,
+`skill-transform` e `goal-tools`.
 
 O pacote expõe os dois contratos como exports importáveis:
 `pantheon-opencode/plugin` (V1), `pantheon-opencode/plugin-v2` (V2) e
@@ -159,13 +179,23 @@ instalador remove referências Pantheon das duas formas de config antes de
 gravar apenas o registro Pantheon selecionado. Entradas de terceiros não são
 convertidas nem reivindicadas por essa regra.
 
-O relatório `pantheon_cost`, disponível nos plugins V1 e V2, pode selecionar o banco com
-`PANTHEON_OPENCODE_VERSION=v1` ou `v2` (`opencode.db` ou `opencode-v2.db`).
-`PANTHEON_COST_DB=/caminho/absoluto/para/opencode.db` tem precedência sobre o
-seletor de versão, e um `dbPath` explícito fornecido pelo chamador da
-ferramenta tem precedência sobre ambos. O resolver nunca consulta o banco da
-outra versão e reporta um erro acionável quando o banco selecionado está
-ausente ou com schema incompatível.
+O relatório `pantheon_cost`, disponível nos plugins V1 e V2, resolve o banco por
+CAMINHO, nesta ordem: um `dbPath` explícito fornecido pelo chamador da
+ferramenta, depois `PANTHEON_COST_DB=/caminho/absoluto/para/opencode.db`,
+depois `OPENCODE_DB`, e por fim o padrão do XDG `opencode.db`. Não há nome de
+arquivo por versão nessa cadeia: `opencode-v2.db` não é um banco de um host 2.x
+— é o nome que um sandbox dá ao próprio banco de estado via `OPENCODE_DB`.
+
+A distinção v1/v2 é o SCHEMA DETECTADO, não o nome do arquivo. O relatório
+procura as tabelas `message` e `session_message` e lê aquele que o banco aberto
+realmente tiver, porque um banco migrado carrega as duas famílias ao mesmo
+tempo. `PANTHEON_OPENCODE_VERSION=v1|v2` não seleciona arquivo nenhum: apenas
+estreita um conjunto já detectado para uma família de tabelas, e falha rápido
+quando o valor não é `v1` nem `v2` ou quando a família pedida não existe lá.
+Sem a variável, todas as famílias detectadas são lidas. Um banco sem nenhuma
+das duas tabelas volta como erro acionável (`CORRUPT_DATA`), e um ledger que
+existe mas não produz tokens legíveis como `UNSUPPORTED` — nunca como um
+relatório vazio com sucesso.
 
 O instalador continua gravando as configurações de compatibilidade exigidas
 pelo host OpenCode selecionado, como `experimental.subagent_depth`; isso não

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pantheon-opencode",
-  "version": "1.6.0-beta.2",
+  "version": "1.6.0-beta.4",
   "description": "Multi-agent orchestration for OpenCode — 14 specialized agents, TDD, Themis review gates.",
   "type": "module",
   "workspaces": [
@@ -46,6 +46,7 @@
     "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:tool-canary": "node --test tests/canary/plugin-v2-tool-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"
@@ -97,20 +98,22 @@
     "!**/*.pyc"
   ],
   "dependencies": {
-    "@opencode-ai/plugin": "1.18.30",
-    "js-yaml": "^4.3.2",
-    "zod": "4.1.8"
+    "@opencode-ai/plugin": "1.18.33",
+    "js-yaml": "^5.4.2",
+    "zod": "4.1.8",
+    "@opencode-ai/sdk": "1.18.33"
   },
   "devDependencies": {
-    "@biomejs/biome": "2.5.13",
-    "@commitlint/cli": "21.2.2",
-    "@commitlint/config-conventional": "21.2.2",
+    "@biomejs/biome": "2.5.14",
+    "@commitlint/cli": "21.2.3",
+    "@commitlint/config-conventional": "21.2.3",
+    "ajv": "8.20.0",
     "husky": "^9.1.7",
-    "tsx": "4.23.13",
-    "typescript": "6.0.3"
+    "tsx": "4.23.15",
+    "typescript": "7.0.2"
   },
   "overrides": {
-    "rolldown": "1.2.0"
+    "rolldown": "1.2.7"
   },
   "repository": {
     "type": "git",

package/plugin.json

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

package/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.backends._legacy:_Backend"
 
 [project]
 name = "pantheon"
-version = "1.6.0-beta.2"
+version = "1.6.0-beta.4"
 description = "Multi-agent orchestration framework"
 requires-python = ">=3.11"
 dependencies = []

package/scripts/code_mode_server.py

@@ -36,7 +36,7 @@ from typing import Any
 
 import yaml
 from _pantheon_paths import pantheon_home, pantheon_project
-from mcp.server.fastmcp import FastMCP
+from fastmcp import FastMCP
 
 # ── Constants ─────────────────────────────────────────────────────────────────
 ALLOWED_EXTENSIONS: frozenset[str] = frozenset({".sh", ".py"})