opencode enforcement: re-deploy fixed adapter to existing installs (execPath fail-close, fixed in #427)

[lantisprime]

Context

#427 fixed a bug where the opencode enforcement adapter fail-closed on every gated tool call in the real opencode/Bun runtime: spawnSync(process.execPath, [bridge.mjs]) spawned the opencode binary (not node), which treated the .mjs path as a project dir, failed to cd, exited 0 with empty stdout → the adapter's JSON.parse threw → "fail-closed: bridge stdout not valid JSON".

The bug has been present since the P5 merge (#424), so the shipped opencode enforcement has been non-functional in real use — it blocked every gated tool call instead of deciding (an enforcement-installed project can't run bash or write files through opencode).

What needs to happen

Any project that installed opencode enforcement before #427 has the broken adapter on disk and needs a re-install to pick up the fix:

node install.mjs --tool opencode --install-enforcement --project <dir>

Tasks

• Identify projects with deployed opencode enforcement (.opencode/plugins/episodic-memory/).
• Re-run the per-project install to redeploy the fixed enforcement.ts.
• Verify post-deploy with the live test (tests/test-opencode-enforcement-live-e2e.mjs) or a manual drive of the real opencode TUI (confirm a gated write is decided, not fail-closed).

Notes

• Root cause + fix + regression test: fix(opencode): spawn real node for the bridge, not process.execPath (Bun-runtime fail-close) #427.
• The regression test drives the actual opencode terminal — the existing proxy/node tests (test-opencode-adapter-conformance.mjs, -adapter.mjs) run under node where process.execPath IS node and structurally could not catch this class. Worth auditing other adapters (codex/pi-agent) for the same process.execPath assumption if they ever run under a non-node host.