OpenCode approval review and resolved modes

[chuks-qua]

Parent

#1621

What to build

OpenCode declares review support through capabilities and side-effect-free inspection, and every review route behaves: automatic with terminal states, visible manual fallback, managed-policy block before dispatch, Full Access without review labels, and strict routing that waits for a real permission request. Dispatch always carries resolved modes.

Decision Sources

• Serve OpenCode sessions through a pooled serve + SDK provider #1621 (capability seam, resolved dispatch modes) and its working companion .dev/verification/opencode-serve-architecture.html.
• Run provider-neutral automatic review for supported turns #1614: small provider interface; available, required, and unavailable outcomes; resolved review and permission modes travel atomically with dispatch.
• Enforce automatic-review fallback and permission safety #1615: manual-required fallback, managed-required block, Full Access separation, strict-routing notice semantics, one terminal outcome per attempt, redacted payloads.
• Needs the server-owned review policy from the Run provider-neutral automatic review for supported turns #1614 slice before this can land.

Acceptance criteria

• Journey: request automatic with support present ÔåÆ reviewing state ÔåÆ exactly one of approved or denied persists.
• Journey: request automatic with support absent ÔåÆ manual-required fallback shown, dispatch proceeds manual only when policy permits.
• Journey: managed policy requires automatic with support absent ÔåÆ dispatch blocked before send with a reason.
• Journey: Full Access turn ÔåÆ no review label anywhere; strict notice alone ÔåÆ turn waits for the real permission request.
• Provider passes the shared review conformance suite as second adapter.

Blocked by

• Minimal OpenCode turn over pooled serve #1622 (plus the server-owned review policy from the Run provider-neutral automatic review for supported turns #1614 slice)

Key references

• Program: Provider-neutral Codex protocol completeness #1610 (provider completeness) — read before starting; its decisions bind this ticket.
• Spec: Serve OpenCode sessions through a pooled serve + SDK provider #1621 — full contracts, diagrams, and sequencing.
• Visual companion: .dev/verification/opencode-serve-architecture.html in the main worktree (topology, turn sequence, state, contract drafts).
• Upstream docs: https://opencode.ai/docs/server/ and https://opencode.ai/docs/sdk/
• Prior art: Synara opencodeRuntime.ts (pooled serve per cwd) and T3 Code Layers/OpenCodeAdapter.ts plus issues #2691, #3601, #3604 (failure modes to avoid).

[chuks-qua]

Implemented in #1769.

What landed:

• getApprovalReviewSupport on the OpenCode adapter, honest unavailable for every input with stable reason opencode-lacks-native-approval-review. Side-effect-free, no probing.
• Resolved modes honored on dispatch. permissionMode: "full" auto-answers upstream permission asks with always through the existing reply path (adapter-side, because the pooled serve is shared per working directory and a config write would leak between threads). Questions still surface as cards. Supervised is unchanged.
• The approval-review capability stays undeclared so the Composer never offers Auto for OpenCode, per the Enforce automatic-review fallback and permission safety #1615 picker rule.
• Provider registered in the shared conformance suite: boundary factory, ProviderBoundary.id, PROVIDER_IDS, and a opencode-core.synthetic.json fixture.

What is not covered, and why:

• The "automatic with support present → approved/denied" journey stays dormant. OpenCode's serve API exposes per-tool permission asks but no turn-level review verdict, so support inspection can only ever report unavailable today. A client-side synthesized review was rejected as a fabricated lifecycle with no enforcement hook. getApprovalReviewSupport is the single place to flip when upstream ships a real primitive (the auto-approve classifier PRs are the closest in-flight work).
• Managed-required blocking is unreachable. The required status is produced by the provider's own inspection and no upstream managed signal exists.
• The conformance registration proves the factory and core-lifecycle seam only; no approval-review profile exists because there is no review behavior to replay.
• Live verification is a coverage gap: opencode CLI was not installed in the verifying environment. Focused tests (102 adapter tests, including 5 new behavior tests) cover the new paths; verify-mcode provider and contract phases pass.