pantheon-opencode 1.6.0-beta.6 → 1.6.0-beta.7

package/CHANGELOG.md

@@ -18,6 +18,122 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## ✅ Closed Issues
 
+## [v1.6.0-beta.7] - 2026-10-10
+
+<!-- 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
+
+- **Simpler agent dispatch:** answer no-change questions directly, send bounded
+  fixes to one specialist, load council instructions on demand, and remove
+  routine per-task KV/cache routing. No token, cost, or latency savings are
+  claimed without live measurements.
+- **V2 install and permissions:** use a versioned package-root plugin pin and
+  migrate V1 `task`/`write` permissions to V2 `subagent`/`edit`, retaining the
+  stricter effect when rules collide.
+- **Release and runtime hardening:** bounded in-process secret scanning,
+  fail-closed V2 registration, TUI timer disposal, truthful doctor reporting,
+  and guarded V2 sandbox prepare/reset.
+
+## 🐞 Fixed
+
+- TUI usage polling now starts only after its optional slot registers and all
+  refresh timers are disposed on shutdown.
+- Doctor detects version drift in string and object V2 package pins, including
+  prerelease versions; checkout installs warn when their exact npm pin is not
+  published yet.
+- V2 permission migration maps `task → subagent` and `write → edit` and
+  preserves the stricter conflicting rule.
+
+## ⚠️ Known Issues
+
+- Live provider E2E is blocked by HTTP 403; an interactive model-backed V2 TUI
+  turn remains unverified.
+- The V2 tool canary targets OpenCode 2.0.22 while the installable CLI differs
+  (issue #216); V1 host end-to-end validation is also deferred.
+- The observed P0-4 tool-catalog oscillation has no reproduced cause; its
+  reproduction harness remains follow-up work.
+- V2 `init` from an unpublished source checkout writes a versioned npm pin that
+  cannot resolve until that version is published; the installer warns.
+## [v1.6.0] - 2026-10-10
+
+This stable candidate consolidates the beta.1–beta.6 changes. The original beta
+entries remain below as historical records so release detail is not discarded.
+
+## 🆕 What's New
+
+- **OpenCode V2 plugin and installer path:** generation detection, V2 plugin
+  registration, three functional V2 tools, read-only enforcement, and explicit
+  reporting of the smaller V2 feature surface. The V1 API path remains in the
+  package, but no V1 host has been exercised end-to-end in this release.
+- **Sandbox validation and release hardening:** fail-closed checks, V2 MCP and
+  hook probes, package/version inventory validation, and reproducible package
+  evidence. The sandbox now generates its runner, isolated TUI launcher, and
+  README during `--prepare`.
+- **Dependency and TUI maintenance:** synchronized release manifests, updated
+  dependency/security overrides, and TUI/runtime consistency checks.
+- **Simpler agent dispatch path:** no-change questions can be answered directly;
+  bounded fixes route to one specialist; council guidance is loaded on demand;
+  and default routing no longer makes per-task KV/cache lookups. Synthetic
+  timeout/session behavior unsupported by the host was removed. These changes
+  simplify the prompt and dispatch path; this release makes no measured token,
+  cost, or latency improvement claim.
+
+## 🐞 Fixed
+
+- `PANTHEON_V2_MCP_LIST_TIMEOUT` now defaults to 15 seconds in both the harness
+  and generated `run-test.sh`, including under `set -u`; the default does not
+  depend on an exported environment variable.
+- `PANTHEON_REPO` is resolved consistently for prepare, generated tests, and
+  reset guards. Relative, dangling, missing, or non-Pantheon paths fail before
+  packaging; `.repo-dir` is atomically written and validated before use.
+- Sandbox prepare/reset reject roots overlapping a checkout or the user's
+  `HOME`. `PANTHEON_V2_PORT` defaults to 49376, is range-checked, and refuses an
+  occupied port without reusing or stopping the existing service.
+- Sandbox `tmp/` is not blanket-deleted: prepare only expires hash-named Node
+  compile-cache files owned by the current user and older than 30 days. Runtime
+  state, unknown entries, and handoff/evidence files remain untouched.
+- **V2 plugin registration is stable across install locations.** `init` now
+  writes the exact `pantheon-opencode@<version>` npm entry and the package root
+  exports the V2 plugin. This replaces absolute paths into a global prefix or
+  transient `npx` cache; `doctor` recognizes the pinned package and reports
+  version drift. A clean production-only package consumer test covers the root
+  export.
+- **V1-to-V2 permissions preserve their intended actions.** Migration maps
+  `task` to V2 `subagent` and `write` to the `edit` action that also governs
+  `write`/`patch`. If V1 `edit` and `write` rules collide on one resource, the
+  more restrictive effect wins. Tests cover global and nested agent rules.
+- **`doctor` distinguishes SQLite readiness from tool registration.** The
+  `node:sqlite` check now says it verifies only the backend prerequisite, not
+  whether `pantheon_cost` registered on the active host.
+- **Release documentation was reconciled with current code.** The V2 caller /
+  target matrix is enforced by `permission.evaluate`; the bridge export is an
+  importable utility but is not wired into production; the V2 event count and
+  package registration format are corrected in both READMEs and the install /
+  upgrade guides.
+
+## ⚠️ Known Issues
+
+- **V1 host canary is deferred.** The tested package dependency pair is
+  `@opencode-ai/plugin@1.18.33` + `@opencode-ai/sdk@1.18.33`; this is not an
+  end-to-end V1 host compatibility claim. No OpenCode `1.18.35` host support is
+  asserted.
+- **V2 support remains partial.** The tool canary was authored against
+  `opencode 2.0.22`; the installable CLI has drifted from that canary contract
+  (tracked in issue #216). See the README compatibility table for the measured
+  evidence and limitations.
+- **Release validation is not complete.** Live provider E2E returned HTTP 403,
+  the interactive V2 TUI/model-backed turn has not been verified, and the
+  previously observed within-session tool-catalog oscillation (P0-4) still has
+  no reproduced cause. This candidate must not be published until the host
+  validation gates are resolved or explicitly waived.
+- **V2 init from an unpublished source checkout cannot bootstrap its own npm
+  pin.** It writes the exact package version and emits a warning; OpenCode
+  cannot resolve that version until it is published. This is limited to
+  running the installer from the repository checkout. After publication, use
+  the npm-installed or `npx` installer for the supported consumer path.
+
 ## [v1.6.0-beta.6] - 2026-10-05
 
 &lt;!-- Add new changes here. Running `node scripts/versioning.mjs apply` will

package/README.md

@@ -64,6 +64,13 @@ Once OpenCode is running, describe the outcome you want:
 ```
 
 Pantheon helps turn that request into a plan and a sequence of reviewed steps.
+For questions that do not require repository changes, Zeus answers directly;
+small, reversible fixes use one specialist dispatch. Discovery, planning,
+parallel work, and council review are reserved for tasks that benefit from them.
+
+For a tiny, bounded repair, invoke `@talos` directly (for example,
+`@talos fix this typo`). That skips the Zeus orchestration call; use `/pantheon`
+for planning, delegation, multi-file work, or quality gates.
 
 ## Who is it for?
 
@@ -82,10 +89,10 @@ clear handoff between stages of work.
 
 ## Status
 
-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
+Candidate version: **1.6.0-beta.7**. The manifests in this checkout express a
+beta candidate, not a confirmed publication; beta publication happens only
+after the explicit Release workflow completes successfully. To check the
+published beta, 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
@@ -128,13 +135,19 @@ host is an unsupported mixed/wrong-generation configuration, not a supported mod
 
 ### What the OpenCode 2 path is — and is not
 
-**Not inert.** The V2 path (`src/plugin-v2`, registered as a directory because
-the V2 loader rejects bare file paths) registers real tools with real
-`input`/`output` schemas via `ctx.tool.transform()`, 5 event subscriptions,
-session hooks and a tool `execute.before` hook that enforces read-only sessions.
-It is a smaller surface than V1 by design, not a stub: the 3 goal tools and the
-V1 caller→target delegation matrix are absent, and `getUnsupportedFeatures()`
-reports that as `goal-tools` and `delegation-matrix`.
+**Not inert.** V2 registers the version-pinned npm package
+`pantheon-opencode@<version>` (pinned to the installed Pantheon version); its
+package-root export points to `src/plugin-v2.ts`.
+It registers real tools with `input`/`output` schemas via
+`ctx.tool.transform()`, five event subscriptions, session hooks, and tool/
+permission hooks for read-only enforcement and the Pantheon caller→target
+delegation matrix. For Pantheon-managed targets, Zeus may delegate to any
+registered agent; Athena and Hermes may target Apollo only; other Pantheon
+callers and unknown callers are denied. Child sessions cannot delegate to
+Pantheon agents. Native/custom targets remain under host permissions. V2 never
+adds an allow grant or overrides an explicit host deny; missing or mismatched
+identity fails closed for a Pantheon delegation. The three goal tools remain
+unsupported and are reported as `goal-tools`.
 
 **Not complete either, and the V2 support claim is currently narrowed.** Two
 facts, both recorded in this repository rather than smoothed over:
@@ -157,14 +170,14 @@ facts, both recorded in this repository rather than smoothed over:
 Treat the 1.6 line's OpenCode 2 support as **real but partial**, and do not read
 the 1.6.x row as "OpenCode 2 is finished".
 
-### Verified against which OpenCode versions
+### Verified dependency and host evidence
 
 | What | Verified against | How |
 |---|---|---|
-| V1 plugin + generation gate | The OpenCode 1.18.x line. This package pins `@opencode-ai/plugin` and `@opencode-ai/sdk` to `1.18.33`; the highest published `opencode-ai` host package (the one shipping the `opencode` binary) is `1.18.34` | Dependency pin (`package.json`); generation-gate unit tests over injected host banners; installer end-to-end tests asserting the emitted `opencode.json` shape |
+| V1 plugin API/generation checks | The dependency pair pinned by this release: `@opencode-ai/plugin@1.18.33` + `@opencode-ai/sdk@1.18.33` | `package.json`; generation-gate unit tests over injected host banners; installer end-to-end tests asserting the emitted `opencode.json` shape. This is not a claim that a V1 host was exercised end-to-end. |
 | V2 plugin tool surface | `opencode 2.0.22` (the host the canary was written against) | `tests/canary/plugin-v2-tool-canary.test.mjs`, driving `hashline_edit` through a real `opencode serve` |
 | V2 against the current installable CLI | **Not verified.** Canary fails 12/12; see issue #216 | — |
-| Exact 1.X host version the 1.6 line is exercised against end-to-end | **Unverified.** No V1 host leg exists: the sandbox runner is V2-only and `--run v1` is rejected | — |
+| Exact 1.X host version exercised end-to-end | **Unverified; V1 host canary deferred.** The sandbox runner is V2-only and `--run v1` is rejected | — |
 
 ## Delegation (native `task()`)
 
@@ -175,6 +188,18 @@ there is no Pantheon-specific delegation tool surface to configure. See
 [ADR-0011](.pantheon/memory-bank/adr/0011-delegation-engine-contract.md) for the
 historical engine contract.
 
+This 1.6.0-beta.7 candidate consolidates the final beta.6 follow-ups: safer
+V2 installation and permission migration, bounded in-process secret scanning,
+sandbox hardening, TUI lifecycle fixes, and a simpler agent dispatch path.
+Zeus answers no-change questions directly and routes bounded fixes once; the
+council procedure is loaded only for a council, without per-task KV/cache
+lookups. Runtime call counts and latency have not been measured. Live provider
+E2E and a model-backed interactive V2 TUI turn remain unverified.
+
+Transient delegation dispatch failures get at most one retry. A refusal or
+failed check is not repeated; after the retry fails, the configured fallback
+chain applies once or Zeus escalates.
+
 ## Cost tool backend
 
 `pantheon_cost` prefers a read-only `node:sqlite` backend against the selected
@@ -264,8 +289,8 @@ per installation; V1 and V2 Pantheon plugins must never be registered together.
 | | V1 | V2 |
 |---|---|---|
 | 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: 3 tools (`hashline_edit`, `pantheon_cost`, `pantheon_model`), 5 event subscriptions, session hooks (`prompt`, `context`), a read-only-enforcing tool `execute.before` hook, plus configuration transforms |
+| Pantheon registration | `src/plugin.ts` plus `src/plugins/pantheon-hooks.ts` | Version-pinned npm package `pantheon-opencode@<version>` (root export loads V2) |
+| Runtime contract | Pantheon V1 plugin: 6 tools (`hashline_edit`, the 3 goal tools, `pantheon_cost`, `pantheon_model`), event/tool hooks and V1 compaction handling | V2 plugin: 3 Pantheon tools when required enforcement registers, 5 event subscriptions, session hooks (`prompt`, `context`), a read-only and secret-scanning `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 3 orchestration tools (`hashline_edit`, `pantheon_cost`,
@@ -285,10 +310,16 @@ surface: the host includes the active agent on the event, a read-only agent
 `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.
+when only `plugin-v2` is configured. The `permission.evaluate` hook enforces
+the V2 caller/target matrix for Pantheon-managed targets across every entry in
+the host's `resources` array. Native-only resources pass through unchanged to
+OpenCode's permission policy; mixed native/Pantheon requests and multi-target
+requests are denied unless every Pantheon target is explicitly allowed for the
+authoritative caller. Explicit host denies remain final, and missing or
+unknown resource data fails closed. If a denied evaluation has no mutable host
+output argument, the hook throws to fail closed rather than silently omitting
+the denial. V2 `execute.after` runs the completed-result chain:
+`task-result-guard` → `context-sandbox` → `read-enhancer`.
 
 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
@@ -297,14 +328,41 @@ 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`
-(optional interop), so a host can load either contract explicitly.
-
-The V1→V2 bridge (`src/pantheon/v2-bridge.ts`) enables optional interop:
-V1 infrastructure singletons (BackgroundJobBoard, GoalStore,
-TodoEnforcer, VisionHandler) are passed through V2 `ctx.options`. The bridge is
-optional — V2 works standalone with graceful degradation.
+When `init --opencode-version v2` migrates a V1-shaped permission config, it
+translates `task` to the V2 `subagent` action and `write` to `edit` (which also
+covers host `write`/`patch`). If legacy `edit` and `write` rules collide on a
+resource, migration keeps the stricter effect. Hand-edited V2 configs should
+use the native top-level `permissions` array and action/resource/effect form.
+
+### Runtime secret-scanning limit
+
+V1 and V2 use the same in-process scanner on their tool `execute.before` paths.
+The scanner accepts up to **5 MiB (5,242,880 UTF-8 bytes) of serialized hook
+payload**. Larger or malformed payloads are denied fail-closed; the rejected
+payload is not written to the scanner log. This bound applies to the complete
+serialized hook payload, not just one argument field. Before calling
+`JSON.stringify`, the scanner iteratively preflights compact JSON byte size,
+including UTF-8 and JSON escapes, and stops as soon as the limit is exceeded.
+It rejects cycles, enumerable accessors and `toJSON` hooks, proxies, excessive
+nesting, and non-JSON values without serializing or logging them.
+
+V2 registers its required enforcement hook before registering Pantheon tools.
+If the host rejects that hook, startup reports `secret-scan-hook` and
+`pantheon-tools-disabled`, and Pantheon V2 tools are not registered. This does
+not disable or claim scanner coverage for native host built-in tools; those may
+remain available under the host's own policies. The opt-in timing harness is
+reproducible with `npx tsx scripts/bench-secret-scanner.ts`: it runs 3 warmups
+and 15 measured calls per size, reporting median timings for the current
+`scanSecretText` implementation on safe ASCII strings only. It excludes payload
+preflight/serialization and host-hook overhead, is not a historical or
+Bash-versus-TypeScript comparison, and makes no speedup claim. It does not print
+scan input.
+
+The package exposes both contracts as importable exports: the package root and
+`pantheon-opencode/plugin-v2` load V2; `pantheon-opencode/plugin` loads V1.
+`pantheon-opencode/v2-bridge` is currently an importable utility only:
+production setup does not wire it into the V2 plugin, so it does not provide
+runtime interoperability or restore V1 goal/board features.
 
 Select the contract explicitly when installing:
 
@@ -321,8 +379,8 @@ the host in this order: an explicit `OPENCODE_VERSION=v1|v2` wins; otherwise an
 binary is asked for its `--version` and a major of 2 or more selects V2. Every
 other case — an unreadable probe, an unparseable banner, or a banner whose
 version-like tokens contradict each other with no tool name to break the tie —
-warns once and falls back to V1, because a plural `plugins` directory entry on
-an unknown 1.x host loses the plugin entirely.
+warns once and falls back to V1, because the V2-only package export is not a
+valid V1 runtime contract on an unknown 1.x host.
 
 The probe prefers the token that follows the tool name, so a runtime token
 ahead of it (`node v22.1.0 (opencode 1.18.33)`) or a trailing build date
@@ -386,8 +444,9 @@ Key order does not matter.
 One command keeps an existing installation current:
 
 ```bash
-# Without a global install, ALWAYS pin the dist-tag — plain `npx
-# pantheon-opencode` resolves `latest`, which is the stable release (1.4.3):
+# Without a global install, pin the intended npm dist-tag. The `latest` tag
+# reflects the most recently published stable release, not an unpublished
+# release candidate:
 npx pantheon-opencode@beta update            # npm beta channel + config refresh
 npx pantheon-opencode@beta update --stable   # stable channel instead
 
@@ -473,6 +532,10 @@ 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.
 
+CI also rebuilds the TUI with `npm run build --prefix src/plugins/tui` and
+checks every packaged `dist` artifact byte-for-byte against its checked-in
+version, including final newlines.
+
 ## Sandbox validation (V2)
 
 `scripts/test-opencode-v2-sandbox.sh` validates the globally installed
@@ -484,10 +547,12 @@ 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`.
+The historical hook canary observed at least one callback on an OpenCode
+v2.0.18 host; the tool canary was written against v2.0.22. Those observations
+do not establish compatibility with the current installable `@opencode-ai/cli@beta`,
+an SDK contract for all of 2.x, or a V1 host. This release pins the V1 plugin
+dependency pair at `@opencode-ai/plugin@1.18.33` and `@opencode-ai/sdk@1.18.33`;
+the V1 host canary remains deferred.
 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
@@ -500,7 +565,7 @@ scripts/test-opencode-v2-sandbox.sh --prompts     # base validation + prompt bat
 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
+scripts/test-opencode-v2-sandbox.sh --reset       # guarded reset of the sandbox root
 ```
 
 Modes are combinable (e.g. `--prepare --run v2 --prompts`). `--rehydrate` runs
@@ -513,8 +578,20 @@ 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.
+always built from the checkout this script lives in unless `PANTHEON_REPO` is
+set to an absolute path for an existing `pantheon-opencode` checkout. The same
+resolved checkout is used by prepare and the generated `run-test.sh`; dangling,
+relative, and non-Pantheon paths fail before packaging. `--prepare` generates
+`run-test.sh`, `start-pantheon.sh`, and a sandbox-local `README.md`.
+
+`PANTHEON_V2_PORT` selects the dedicated loopback port (default `49376`). The
+harness validates the port and refuses an occupied listener without reusing or
+stopping it. `PANTHEON_V2_HOST` defaults to `127.0.0.1` and rejects non-loopback
+addresses. `PANTHEON_V2_MCP_LIST_TIMEOUT` controls each `mcp list` call
+(default `15` seconds). On prepare, only hash-named Node compile-cache files
+owned by the current user and older than 30 days may expire under
+`tmp/node-compile-cache`; runtime state and unrecognized files (including
+handoff evidence) are preserved.
 
 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.
@@ -591,6 +668,22 @@ Ideas, bug reports, documentation improvements, and code contributions are
 welcome. Please read [CONTRIBUTING.md](CONTRIBUTING.md) before opening an issue
 or pull request.
 
+### Reproducible benchmark evidence
+
+The beta2 benchmark records reported token usage separately from its
+character-based fallback estimate; source bytes and logical line counts remain
+provenance data and are never converted into tokens. Cross-report comparisons
+require matching model/config provenance and reported OpenCode usage. Offline
+fixture responses are mocked: their reported values are labeled separately,
+excluded from `actual` usage, and blocked from comparative metrics and GEPA.
+Fixture quality outcomes test the offline contract; they are not evaluation
+evidence.
+Reproduce the
+checked-in AGENTS.md history manifest with
+`python3 -m benchmarks.beta2.provenance --output benchmarks/beta2/fixtures/agent-baseline-provenance.json`.
+For OpenCode benchmark runs, provide `--model` and `--config-sha256` so reports
+can be compared safely.
+
 ### Project-level `opencode.json`
 
 The published package carries no `opencode.json` template. `init` still writes

package/README.pt-BR.md

@@ -53,6 +53,19 @@ Com o OpenCode em execução, descreva o resultado que você quer:
 ```
 
 O Pantheon ajuda a transformar esse pedido em um plano e em etapas revisadas.
+Perguntas sem mudança no repositório são respondidas diretamente; correções
+pequenas usam uma única delegação. Discovery, planejamento, paralelismo e
+revisão em council ficam para quando o escopo ou o risco justificarem.
+
+Para uma correção pequena e bem delimitada, chame `@talos` diretamente (por
+exemplo, `@talos corrija este typo`). Assim você pula a chamada de orquestração
+do Zeus; use `/pantheon` para planejamento, delegação, mudanças em vários
+arquivos ou gates de qualidade.
+
+O procedimento completo de council só é carregado em `/pantheon` ou quando uma
+decisão material realmente exige perspectivas distintas. Falhas de dispatch
+podem ser tentadas novamente uma vez; testes reprovados e recusas não são
+repetidos automaticamente.
 
 ## Para quem é?
 
@@ -71,11 +84,13 @@ verificações repetíveis e passagens claras entre etapas do trabalho.
 
 ## Status
 
-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.
+Versão candidata neste checkout: **v1.6.0-beta.7** (manifestos preparados;
+publicação ainda não confirmada). Para verificar a beta publicada, consulte a
+dist-tag `beta` do npm. O histórico permanece no [changelog](CHANGELOG.md). 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.
 
 
 ## Execução code-mode (opt-in explícito)
@@ -121,13 +136,13 @@ registrados juntos.
 | | V1 | V2 |
 |---|---|---|
 | 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: 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 |
+| Registro Pantheon | `src/plugin.ts` mais `src/plugins/pantheon-hooks.ts` | pacote npm `pantheon-opencode@<versão>` fixado à versão instalada (export raiz aponta para `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: 3 ferramentas (`hashline_edit`, `pantheon_cost`, `pantheon_model`), 5 assinaturas de eventos, session hooks (`prompt`, `context`), hooks de execução/permissão e 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 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`,
+`pantheon_cost`, `pantheon_model`), 5 assinaturas de eventos (`session.created`,
+`session.idle`, `session.deleted`, `session.error`, `session.compacted`), session hooks (`prompt`,
 `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
@@ -141,10 +156,16 @@ dessa superfície: o host inclui o agente ativo no evento, um agente somente-lei
 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.
+quando apenas `plugin-v2` está configurado. O hook `permission.evaluate`
+aplica no V2 a matriz caller/target para destinos gerenciados pelo Pantheon,
+considerando todos os itens do array `resources` do host. Recursos
+exclusivamente nativos são repassados sem alteração à política de permissões do
+OpenCode; pedidos mistos (nativos/Pantheon) e com vários destinos são negados,
+a menos que todos os destinos Pantheon sejam explicitamente permitidos para o
+chamador autoritativo. Uma negação explícita do host é final, e dados de
+recursos ausentes ou desconhecidos são negados por padrão. O `execute.after` do
+V2 executa a cadeia de resultados concluídos `task-result-guard` →
+`context-sandbox` → `read-enhancer`; eventos de erro permanecem inalterados.
 
 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
@@ -153,15 +174,18 @@ 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
-`pantheon-opencode/v2-bridge` (interop opcional), para que o host carregue
-explicitamente o contrato desejado.
+Ao migrar uma config V1 com `init --opencode-version v2`, o instalador traduz
+`task` para a ação V2 `subagent` e `write` para `edit` (que também cobre as
+tools host `write`/`patch`). Se regras legadas `edit` e `write` colidirem no
+mesmo recurso, a migração preserva o efeito mais restritivo. Configs V2
+editadas manualmente devem usar o array nativo `permissions` com
+`action`/`resource`/`effect`.
 
-A ponte V1→V2 (`src/pantheon/v2-bridge.ts`) habilita interop opcional:
-singletons de infraestrutura V1 (BackgroundJobBoard,
-GoalStore, TodoEnforcer, VisionHandler) são repassados via `ctx.options` do V2.
-A ponte é opcional — o V2 funciona standalone com degradação graciosa.
+O pacote expõe os dois contratos: a raiz e `pantheon-opencode/plugin-v2`
+carregam V2; `pantheon-opencode/plugin` carrega V1. `pantheon-opencode/v2-bridge`
+é atualmente apenas uma utility importável: o setup de produção não a conecta
+ao plugin V2, então ela não fornece interoperabilidade em runtime nem restaura
+as ferramentas de goal/board do V1.
 
 Selecione o contrato explicitamente na instalação:
 
@@ -238,8 +262,8 @@ pontos. A ordem das chaves não muda o resultado.
 Um comando mantém uma instalação existente em dia:
 
 ```bash
-# Sem instalação global, SEMPRE fixe o dist-tag — `npx pantheon-opencode`
-# puro resolve a tag `latest`, que é o release estável (1.4.3):
+# Sem instalação global, fixe o dist-tag desejado. `latest` aponta para a
+# release estável publicada mais recente, não para um candidato não publicado:
 npx pantheon-opencode@beta update            # canal beta do npm + refresh do config
 npx pantheon-opencode@beta update --stable   # canal estável
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pantheon-opencode",
-  "version": "1.6.0-beta.6",
+  "version": "1.6.0-beta.7",
   "description": "Multi-agent orchestration for OpenCode — 14 specialized agents, TDD, Themis review gates.",
   "type": "module",
   "workspaces": [
@@ -11,6 +11,7 @@
     "registry": "https://registry.npmjs.org/"
   },
   "exports": {
+    ".": "./src/plugin-v2.ts",
     "./plugin": "./src/plugin.ts",
     "./plugin-v2": "./src/plugin-v2.ts",
     "./v2-bridge": "./src/pantheon/v2-bridge.ts"
@@ -112,8 +113,12 @@
     "typescript": "7.0.2"
   },
   "overrides": {
+    "@babel/core": "7.29.7",
+    "seroval": "1.6.8",
+    "solid-js": "1.9.12",
     "rolldown": "1.2.7"
   },
+  "//overrides": "TUI production advisory fixes: Babel >=7.29.6 and Seroval >=1.6.3; Solid stays at 1.9.12 to satisfy OpenTUI's exact peer. Remove only after upstream ranges include fixed versions; Seroval compatibility is covered by the Solid serializer regression test.",
   "repository": {
     "type": "git",
     "url": "https://github.com/ils15/pantheon-opencode.git"

package/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "pantheon",
   "publisher": "ils15",
-  "version": "1.6.0-beta.6",
+  "version": "1.6.0-beta.7",
   "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.6"
+version = "1.6.0-beta.7"
 description = "Multi-agent orchestration framework"
 requires-python = ">=3.11"
 dependencies = []
@@ -16,6 +16,7 @@ dependencies = []
 testpaths = [
     "tests",
     "benchmarks/beta2/test_beta2.py",
+    "benchmarks/beta2/test_t1.py",
 ]
 asyncio_mode = "auto"
 addopts = "-v --tb=short"
@@ -48,6 +49,7 @@ select = ["E", "F", "W", "I", "N", "UP", "B", "SIM", "PL", "RUF", "C901"]
 "tests/test_code_mode_frontmatter.py" = ["PLR2004"]
 "tests/test_eval.py" = ["PLR2004"]
 "tests/test_mcp_persistence_server.py" = ["PLR2004"]
+"benchmarks/beta2/test_t1.py" = ["PLR2004"]
 
 [tool.mypy]
 python_version = "3.11"