pantheon-opencode 1.6.0-beta.10 → 1.6.0-beta.12

package/AGENTS.global.md

@@ -1,7 +1,7 @@
 <!-- pantheon:generated:begin — Pantheon-managed region; regenerated on install/upgrade, never edit inside -->
 <!-- Generated by scripts/build-agents-md.mjs — do not edit directly. -->
 <!-- Source of truth: src/instructions/*.instructions.md + the static sections in this script. -->
-<!-- pantheon:agents-md v2 artifact=global generated-at=2026-10-14T15:44:12-03:00 sha=a305942 -->
+<!-- pantheon:agents-md v2 artifact=global generated-at=2026-10-16T15:32:02-03:00 sha=2cda37c -->
 
 # Pantheon Agent System — OpenCode
 
@@ -76,7 +76,7 @@ the complete plan in the current conversation before requesting approval.
 
 ## Council Specialist Response Format
 
-When responding to a `/pantheon` council synthesis invocation, specialists MUST return this structured format:
+When responding to a `/pantheon` council synthesis invocation, specialists MUST return this structured format. First-round specialists receive independent prompts without peer responses, whether dispatch is parallel or synchronous/sequential; they therefore cannot know actual peer positions. Do not guess them, claim agreement/disagreement with unseen peers, or self-reference in agreement signals. Omit `agreement_signals` or write `none` in the first round. In a rebuttal round, signals may reference only peer responses included in that round's prompt. Zeus derives agreement and disagreement during synthesis by comparing actual responses.
 
 ```
 ## specialist_response
@@ -85,8 +85,8 @@ When responding to a `/pantheon` council synthesis invocation, specialists MUST
 **trade_offs:** <what's gained vs lost, specific>
 **risks:** <what could go wrong, max 3 items>
 **confidence:** High | Medium | Low
-**agreement_signals:** agree:@agent1 on <issue>, agree:@agent2 on <issue> | disagree:@agent3 on <issue>
-**specific_claims:** <count of specific factual claims in response>
+**agreement_signals:** <omit or `none` in first round; rebuttal may cite only visible peer responses>
+**specific_claims:** <optional self-reported count; advisory only, not evidence>
 ```
 
 ### Field Rules
@@ -98,29 +98,31 @@ When responding to a `/pantheon` council synthesis invocation, specialists MUST
 | trade_offs | ✅ | At least one gain and one loss, specific to context |
 | risks | ✅ | Max 3 bullet points |
 | confidence | ✅ | One of: High, Medium, Low |
-| agreement_signals | Optional | Format: `agree:@agent on issue \| disagree:@agent on issue`. Use only when you can reference other specialists expected positions. |
-| specific_claims | ✅ | Integer count of verifiable factual statements in the response |
+| agreement_signals | Optional | Omit or use `none` in the first round. In rebuttal, reference only peer responses visible in the prompt; never speculate or self-reference. Zeus derives synthesis positions from actual responses, not these signals. |
+| specific_claims | Optional | Self-reported integer count only; advisory and not independently validated. Do not treat the count alone as evidence or proof of confidence. |
 
 ### Confidence Guidelines
 
-- **High**: Position backed by 3+ specific claims with evidence or direct experience
-- **Medium**: Position backed by 1-2 specific claims
+- **High**: Position backed by at least 3 verifiable claims supported by evidence in the response; a self-reported count alone does not qualify
+- **Medium**: Position backed by at least 1 verifiable claim supported by evidence in the response
 - **Low**: Position is opinion-based or speculative
 
+Equal self-reported counts (for example, several specialists each reporting 7) do not by themselves prove fabrication; assess whether the actual response contains verifiable, supported claims.
+
 ### Example
 ```
 ## specialist_response
-**position:** The BackgroundJobBoard should be used for council crash recovery
-**reasoning:** The board already supports running→completed→reconciled state machine with persistence. Registering council dispatches there adds ~50ms overhead but prevents total session loss on context crash. The WAL pattern ensures no data loss on restart.
-**trade_offs:** Gain: crash recovery for multi-minute council sessions. Lose: ~50ms registration overhead per council.
-**risks:** Board persistence failure could block council start — implement with fire-and-forget error handling
-**confidence:** High
-**agreement_signals:** agree:@themis on persist-before-notify
-**specific_claims:** 3
+**position:** Use a bounded local cache for the read-heavy endpoint.
+**reasoning:** The endpoint repeatedly reads the same reference data. A bounded cache reduces repeated lookups, while a short TTL limits staleness.
+**trade_offs:** Gain: fewer repeated reads. Lose: results may remain stale until the TTL expires.
+**risks:** Cache invalidation may lag after updates.
+**confidence:** Medium
+**agreement_signals:** none
+**specific_claims:** 2 (self-reported; advisory)
 ```
 
 ## Memory Context
-If memory affected the result, state the takeaway briefly; do not repeat the entry or task context.
+If memory affected the result, state the takeaway briefly; do not repeat the entry or task context. If persistence was expected but no write tool was exposed or a write failed, state that it was not persisted; never imply a successful store without confirmation.
 
 <!-- Source: src/instructions/memory-protocol.instructions.md -->
 ## Memory Protocol
@@ -138,12 +140,34 @@ These rules apply to all agents; each agent file may add domain-specific rules.
 - Use a targeted query (`top_k=2`); do not search the whole prompt by default. Missing or irrelevant results never block current work.
 
 ### Persistence
-- `memory_store()` is manual, not automatic. Store at most one concise, reusable top-level result; never persist routine child summaries, phase updates, test logs, or temporary state.
-- Confirm the store succeeded before claiming persistence. There is no automatic memory WAL or recovery. Add ADRs to the memory bank only when explicitly requested.
+- Tool grants vary by agent/runtime. Zeus's installed allowlist has `memory_search` and temporary `context_save`/`context_get` checkpoints, but no durable writes; Mnemosyne's includes `memory_store` and other durable-memory tools. Use only tools exposed and permitted in the active session.
+- Store at most one concise, reusable top-level result; never persist routine child summaries, phase updates, test logs, or temporary state. Confirm a successful write before claiming persistence. Never store secrets, credentials, or tokens. `memory_store` stores submitted values and metadata without guaranteed redaction; omit sensitive content or redact it before storage.
+- If no write tool is available or the write did not succeed, say that the information was not persisted. Do not imply automatic memory storage or recovery. Add ADRs to the memory bank only when explicitly requested.
 
 ### Relevance and permanent records
 Ignore weak matches; routine summaries do not belong in durable memory.
 
+<!-- Source: src/instructions/test-economy.instructions.md -->
+## Test Economy
+
+
+Write the smallest test that proves the behavior: one behavior → one focused
+test, never the same coverage duplicated across suites or files.
+
+- Do NOT add E2E, full-install, or network-dependent tests unless the change
+  actually alters that end-to-end path. Prefer unit or integration tests.
+- Do not assert on copy/format strings redundantly, and do not write
+  assertions that only restate the implementation ("test the test").
+- Heavy or slow suites (e.g. real install/E2E) MUST be opt-in via a separate
+  script/tier. Never run them per edit or per phase; run only the affected
+  subset.
+- Respect a per-phase validation time budget: if a suite takes minutes,
+  justify running it and prefer the targeted subset. Reserve the full heavy
+  suites for release gates.
+- Fixing a bug: add one targeted regression test, not a broad new suite.
+- This economy rule does NOT weaken stronger gates: auth, security,
+  data-integrity, and required coverage thresholds stay mandatory.
+
 <!-- Source: src/instructions/yagni.instructions.md -->
 ## YAGNI Anti-overengineering
 

package/AGENTS.md

@@ -1,7 +1,7 @@
 <!-- pantheon:generated:begin — Pantheon-managed region; regenerated on install/upgrade, never edit inside -->
 <!-- Generated by scripts/build-agents-md.mjs — do not edit directly. -->
 <!-- Source of truth: the static project sections in scripts/build-agents-md.mjs. -->
-<!-- pantheon:agents-md v2 artifact=project generated-at=2026-10-14T15:44:12-03:00 sha=a305942 -->
+<!-- pantheon:agents-md v2 artifact=project generated-at=2026-10-16T15:32:02-03:00 sha=2cda37c -->
 
 # Pantheon — Repository Setup
 

package/CHANGELOG.md

@@ -18,6 +18,52 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## ✅ Closed Issues
 
+## [v1.6.0-beta.12] - 2026-10-17
+
+## 🆕 What's New
+
+- **Raise the Node.js support floor to 26.4.0** for the package, CLI, installer,
+  and Node-based tooling. This release drops Node 22, Node 24, and Node
+  26.0–26.3; the npm `beta` dist-tag remains the intended publication channel.
+- **Clarify runtime boundaries:** this package requirement is not a universal
+  OpenCode host-runtime claim. Official OpenCode V2.0.31 has a Bun runtime path
+  and a separate Node build pinned to 26.4.0; no Bun minimum is asserted.
+- **Keep `node:sqlite` as a separate capability threshold:** Node >=22.5 may
+  provide the optional `pantheon_cost` backend, but does not imply package
+  support on that Node version.
+- **Recommend a persistent external Git worktree location** in interactive TTY
+  setup summaries and the shipped worktrees skill. This is guidance only;
+  Pantheon does not create worktrees or directories automatically.
+
+## 🐞 Fixed
+
+- **Synchronize Beta 12 version metadata and Node engine policy** across package
+  manifests, locks, citation/release metadata, CLI guards, doctor, and CI.
+
+## [v1.6.0-beta.11] - 2026-10-15
+
+## 🆕 What's New
+
+- **record final Beta 11 scope decisions**
+- **record Setup delivery and final-gate lessons in roadmap**
+- **forbid hook bypass in Iris commit contract**
+- **add installer failure reporting and secret-safe output audit**
+- **detect drift between installer plan and apply**
+- **require explicit --yes authorization before installer apply**
+- **exact installer backup set with restore**
+- **add Beta 11 test-economy requirement to shared instructions**
+- **preview per-file change set in installer dry-run**
+- **reconcile Beta 11 roadmap status with completed phases**
+- **describe pantheon_cost window and aggregation limits**
+- **align lean-flow guidance and cost wording**
+- **add project-scoped V2 model overrides**
+- **align host tool and background contracts**
+
+## 🐞 Fixed
+
+- **restore explicit "both" in zeus memory operations instruction**
+- **correct council protocol and persistence bounds**
+
 ## [v1.6.0-beta.10] - 2026-10-12
 
 ## 🆕 What's New

package/README.md

@@ -31,16 +31,17 @@ way to plan work, make progress, check results, and keep useful project context.
 ## Start in 2 minutes
 
 Requirements: [OpenCode 1.18.4+](https://opencode.ai/docs/) and Node.js
-22.22.2+ (or 24.15.0+ / 26+). For which OpenCode generation each Pantheon
-release line supports, see
+26.4.0+ for the Pantheon CLI, installer, and Node-based tooling. For which
+OpenCode generation each Pantheon release line supports, see
 [Compatibility and support policy](#compatibility-and-support-policy).
 
-Pantheon declares `engines.node` as `^22.22.2 || ^24.15.0 || >=26.0.0`. The
-floor reflects what the dependency tree actually needs — the transitive
-`ini@7` rejects earlier 22.x/24.x builds with `EBADENGINE` — and odd-numbered
-Node releases (23, 25) are out of range. The `pantheon_cost` tool also needs
-`node:sqlite`, which requires Node >= 22.5; `doctor` warns when the running
-runtime cannot load it.
+Pantheon declares `engines.node` as `>=26.4.0`; Node 22, Node 24, and Node
+26.0–26.3 are not supported by this release. This package floor does not imply
+that every OpenCode host runs on Node: official OpenCode V2.0.31 has a Bun
+runtime path and a separate Node build pinned to Node 26.4.0. No Bun minimum is
+asserted here. The optional `pantheon_cost` SQLite backend has its own capability
+threshold, `node:sqlite` on Node >= 22.5; that feature threshold does not lower
+Pantheon's package or CLI support floor.
 
 From the project where you want to use Pantheon:
 
@@ -52,6 +53,64 @@ 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).
+
+In an interactive TTY setup summary, Pantheon recommends the persistent
+external worktree location
+`<project-parent>/.pantheon-worktrees/<exact-repository-directory-basename>/<task>`
+(for example, `/home/user/.pantheon-worktrees/My Project/feature-name`). Use the
+project directory's exact basename, including spaces; do not normalize it into
+a slug. This is guidance for future agent work only; Pantheon does not create
+Git worktrees or directories automatically. See the shipped
+[worktrees skill](src/skills/worktrees/SKILL.md) for the agent workflow.
+
+A non-interactive apply requires `--yes` (alias `-y`): without a TTY and
+without `--yes`, `init` prints the change plan and applies nothing. Exit codes:
+`0` success or plan/no-apply, `1` failure, `2` apply requested without
+authorization, `3` drift (a planned target changed before apply), `130` canceled.
+
+Preview with `init --dry-run`. To review and apply across separate invocations,
+save a versioned plan and then explicitly authorize it:
+
+```bash
+npx pantheon-opencode init --dry-run --project --no-mcp --components agents \
+  --save-plan .pantheon-install-plan.json
+npx pantheon-opencode init --apply-plan .pantheon-install-plan.json --yes
+npx pantheon-opencode init --dry-run --json  # machine-readable preview on stdout
+```
+
+Saved plans use mode `0600`, contain operation metadata and fingerprints rather
+than generated file contents, and are bound to their original target and plan
+file path. Applying rechecks the package source and destination snapshots; drift
+aborts before writes. Saved plans do not support `--force`/`--clean`, and
+machine-readable previews reject those options because clean performs bulk removal.
+A dry-run skips probing the OpenCode host to avoid host-side writes; when no version hint
+is configured, it assumes V1 and reports that advisory. Pass
+`--opencode-version v1|v2` to preview a specific generation.
+Saving an artifact is supported on Linux, Darwin, FreeBSD, OpenBSD, and NetBSD
+when the required descriptor paths and filesystem flags are usable. Cross-platform
+behavior has not been fully tested; unsupported platforms fail closed rather
+than risk writing through a replaced parent directory.
+Previews describe managed-file operations, not every bulk or external effect
+(such as Python environment setup). The `postinstall`/`sync-tui` step also only
+refreshes TUI artifacts and is outside this approval flow.
+
+Before the first managed-file write, `init` saves an exact backup set under
+`.pantheon/backups/<timestamp>/` (directory `0700`, files `0600`, the 5 most
+recent kept); it is a byte-for-byte copy and therefore also contains any API
+keys or tokens already present in your files — it is never printed. Recover with
+`pantheon-opencode restore [--project] [--yes]`. There is no automatic rollback;
+an interrupted apply is recoverable from the backup in the same way.
+To remove Pantheon-managed files, review with
+`pantheon-opencode uninstall --project --dry-run` (or `--global`) before applying
+with `--force`. The opt-in `--purge-data` removes only a verified install-state
+file and never removes recovery backups; see the installation guide for details.
+New installs also record a versioned per-file ownership inventory. Review stale,
+unchanged installer-owned files with `pantheon-opencode reconcile --project --dry-run`
+(or `--global --dry-run`); preview is read-only, and apply requires `--apply --yes` or a
+saved reviewed plan. Legacy files without inventory, modified files, and
+symlinks are preserved for manual review. An explicit `--target PATH` uses project
+layout; combine it with `--global` to select the flat global layout. 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).
 The installer also turns each agent's `mcp_tools` allowlist into native
@@ -182,12 +241,17 @@ session/compaction hooks, so the 1.6 line is not full V2 feature parity.
 | V2 native subagent admission | OpenCode v2.0.29 | `tests/canary/run-v2-permission-proof.sh`; identity, root/child checks and permission-before-child ordering are recorded in [`bench/results/f4a-v229-admission-identity-2026-10-14.md`](bench/results/f4a-v229-admission-identity-2026-10-14.md) |
 | 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 | — |
 
-## Delegation (native `task()`)
-
-Pantheon delegates exclusively through OpenCode's native `task()` child-session
-engine. The former custom `pantheon_delegate` tool and the V1 delegation engine
-(`delegation.ts`, `delegate-manager.ts` and supporting modules) were removed;
-there is no Pantheon-specific delegation tool surface to configure. See
+## Delegation (root `subagent`; host/API `task()`)
+
+The host's child-session engine is referred to as native `task()` in API and
+implementation documentation. In the user-reported Beta 10 Zeus-root runtime,
+the callable dispatch tool was `subagent`; `task()` was not exposed as a root
+tool. Treat the API name and examples below as host/API terminology, not a
+guaranteed root-tool name or signature. The active runtime determines the
+`subagent` schema, background options, and completion observability. The former
+custom `pantheon_delegate` tool and the V1 delegation engine (`delegation.ts`,
+`delegate-manager.ts` and supporting modules) were removed; 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.
 
@@ -210,8 +274,12 @@ global database. Both OpenCode services were running, so the 404 in the global
 log may come from the other instance; this remains an end-to-end verification
 item.
 
-Delegated tasks get at most one retry after an initial timeout or failure. If
-that retry fails, the configured fallback or escalation chain applies.
+Delegated work gets at most one retry after an initial transient failure. If no
+completion/status tool is exposed, prefer synchronous `subagent` dispatch or
+wait for a host-provided completion notification; do not assume polling,
+cancellation, job tracking, or board-based recovery. If the runtime does not
+make completion observable, report that limitation. The configured fallback or
+escalation chain still applies.
 
 ## Cost tool backend
 
@@ -228,7 +296,9 @@ available.
 
 | Variable | Default | Purpose |
 |----------|---------|---------|
-| `PANTHEON_NODE` | `node` from `PATH` | Path to a Node.js >= 22.5 binary used by the CLI fallback; an explicit path must exist and be executable, otherwise the tool fails fast instead of ignoring the override |
+| `PANTHEON_NODE` | `node` from `PATH` | Path to a Node.js >= 22.5 binary used only for the `node:sqlite` capability in the CLI fallback; this is not the Pantheon package support floor. An explicit path must exist and be executable, otherwise the tool fails fast instead of ignoring the override |
+
+Tool interpretation matters: `pantheon_model status` reports configuration, not the model serving a completion. V2 manual model overrides are project-only; global override files are neither read nor applied, and global mutation is unsupported until a future surface can obtain separate explicit human authorization. V2 ignores static presets and applies only explicit per-agent project model/variant overrides, leaving the host default unchanged otherwise; V1 preset behavior remains legacy pending compatibility decisions. `pantheon_cost` is a rolling token aggregate, not a session-level or monetary cost report. See the [OpenCode plugin tool notes](docs/mcp-tools.md#opencode-plugin-tools) for details and measurement limits.
 
 
 ## Code-mode execution (explicit opt-in)
@@ -515,13 +585,10 @@ 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):
-npx pantheon-opencode@beta update            # npm beta channel + config refresh
-npx pantheon-opencode@beta update --stable   # stable channel instead
-
-# With a global install, use the global bin (defaults to the beta channel):
-pantheon-opencode update
+# Install globally first; update refuses local, workspace, and npx copies.
+npm install -g pantheon-opencode@beta
+pantheon-opencode update            # npm beta channel + config refresh
+pantheon-opencode update --stable   # stable channel instead
 ```
 
 `update` compares your installed version with the npm dist-tag, runs
@@ -550,23 +617,35 @@ Two freshness guarantees back it up:
   current package.
 
 `init` also gained `--components agents,skills,...` (narrow install),
-`--clean` (alias of `--force`), `--opencode-version auto`, atomic config
-writes with an `opencode.json.bak` backup, preflight checks for python3/npm
-before any file is written, and a non-fatal Python runtime: if the venv fails,
-the install completes but MCP entries are omitted (with a warning) instead of
-pointing at a broken interpreter. Installer messages auto-detect pt-BR via
-`LANG`/`LC_ALL`.
+`--clean` (alias of `--force`), `--opencode-version auto`, preflight checks for
+python3/npm before any file is written, and a non-fatal Python runtime: if the
+venv fails, the install completes but MCP entries are omitted (with a warning)
+instead of pointing at a broken interpreter. Before the first modifying write,
+`init` preserves, byte-for-byte, every regular file it can modify or remove
+inside the config dir (including files a `--clean` run deletes) under
+`.pantheon/backups/<timestamp>/` (directory `0700`, files `0600`, kept 5 deep);
+bulk directories
+(`.venv`, the plugin's `node_modules`) and out-of-target global files
+(`tui.json` copies elsewhere, the global `opencode-vision.json`) are listed in
+the manifest as `notRevertible` rather than silently omitted. The exact-set
+warning is printed once and never echoes file contents. Restore with
+`pantheon-opencode restore [--project] [--yes]` (the old `opencode.json.bak`
+sidecar is gone; the global vision config keeps its own `.bak`). Installer
+messages auto-detect pt-BR via `LANG`/`LC_ALL`.
 
 ## Migrating to 1.5.x (from 1.4.x)
 
 1.5.0 removed the custom `pantheon_delegate` tool (and the V1 delegation
-engine) in favor of OpenCode's native `task()`; see
-[Delegation (native `task()`)](#delegation-native-task). Two things change on
+engine) in favor of the host child-session engine; see
+[Delegation (`subagent` / host API `task()`)](#delegation-root-subagent-hostapi-task). In the
+reported Beta 10 runtime Zeus dispatches through `subagent`; `task()` remains
+host/API terminology, not a guaranteed root tool. Two things change on
 an existing install:
 
 1. **The tool disappears from the plugin surface.** `pantheon_delegate` is no
    longer registered by `src/plugin.ts` or `src/plugin-v2.ts`. Agents now
-   delegate through `task()` only — no configuration is needed.
+   delegate through the dispatch tool actually exposed by the active runtime —
+   no Pantheon-specific delegation tool configuration is needed.
 2. **A lockfile-pinned copy can keep the old tool alive.** `npm install` is
    lockfile-authoritative: a `package-lock.json` pinned to `1.4.1` (which
    satisfies `^1.4.1`) is never re-resolved, so a project's
@@ -811,7 +890,7 @@ or whole-file binary classification. The host-backed evidence is in
 
 `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
+for `src/plugin-v2.ts` only. It requires Node `>=26.4.0`; branch and function
 coverage are reported but are not gates. This is not a repository-wide coverage
 claim.
 
@@ -839,13 +918,18 @@ with the other.
 
 ### Task-result guard
 
-A `task-result-guard` intercepts calls to the native `task()` tool where the
-child session returns an empty or missing result. Instead of surfacing a silent
+A `task-result-guard` intercepts host/API child-session dispatch calls where the
+child session returns an empty or missing result. In the reported Beta 10 Zeus
+root, dispatch is exposed as `subagent`; host/API `task()` terminology does not
+guarantee a root tool by that name. Instead of surfacing a silent
 `completed` with no payload (which confuses the orchestrator), the guard now
 raises an explicit error. This catches the common free-tier failure mode where a
 child session exceeds the uncached-prefill token budget (`BackendAdmissionRejected`)
-and returns nothing. Prefer `background=true` dispatches with an explicit
-`task_status(wait=true)` fan-in so large payloads are collected deterministically.
+and returns nothing. Background dispatch and status/fan-in facilities are
+runtime-dependent. The reported Beta 10 Zeus root did not expose `task_status`;
+use synchronous `subagent` dispatch or wait for a host-provided completion
+notification when no status tool is visible. Do not claim deterministic fan-in
+or job recovery without an exposed, verified mechanism.
 
 
 ## Configuration (environment variables)

package/README.pt-BR.md

@@ -31,7 +31,9 @@ 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.22.2 || ^24.15.0 || >=26.0.0`.
+Requisitos: [OpenCode 1.18.4+](https://opencode.ai/docs/) e Node.js `>=26.4.0` para a CLI, o instalador e as ferramentas Node do Pantheon. Node 22, Node 24 e Node 26.0–26.3 não são compatíveis com esta versão.
+
+Esse requisito do pacote não significa que todo host OpenCode execute Node: o OpenCode V2.0.31 oficial oferece um caminho de runtime Bun e um build Node separado fixado em Node 26.4.0. Não há aqui um requisito mínimo para Bun. O backend SQLite opcional de `pantheon_cost` tem um limite de capacidade distinto (`node:sqlite` requer Node >=22.5), que não reduz o requisito de suporte do pacote.
 
 No projeto em que você quer usar o Pantheon:
 
@@ -75,8 +77,7 @@ 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
+Versão operacional neste checkout: **v1.6.0-beta.12** (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.
@@ -536,7 +537,7 @@ anteriores foram preservadas separadamente em
 
 `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`;
+cobertura de linhas somente para `src/plugin-v2.ts`. Requer Node `>=26.4.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.