Docs/recipe: OpenCode Zen professional fallback profile with GPT-5.5 xhigh plan/review + Sonnet builder

[BaseInfinity]

Summary

I installed opencode-sdlc-wizard into an existing repo and configured a professional OpenCode Zen fallback lane:

• Plan: GPT-5.5 at xhigh reasoning — opencode/gpt-5.5
• Build: Claude Sonnet 4.6 — opencode/claude-sonnet-4-6
• Review: GPT-5.5 at xhigh reasoning — opencode/gpt-5.5 (merge-blocking subagent)
• Provider isolation: enabled_providers: ["opencode"] so the lane can only use Zen and cannot touch my Claude Code / Codex / ChatGPT subscription pools.

This is a deliberate "third lane": Claude Code + Opus and Codex + GPT-5.5 are lanes 1 and 2; this Zen lane is a separate budget/quota for when those are exhausted.

Why this matters

Lots of developers already run Claude Code and Codex but want a separate, reliable third budget with strict provider isolation. The wizard is a great fit because it enforces Plan -> TDD -> self-review while staying backend-agnostic. The missing piece is a documented, copy-pasteable "Zen professional fallback profile" that wires the three canonical agents (plan/build/review) to specific Zen model IDs with the right reasoning effort and permission sandbox — without a multi-agent swarm.

What worked

• Install was clean and non-destructive. Ran:
  • npx opencode-sdlc-wizard@latest init --dry-run (preview)
  • npx opencode-sdlc-wizard@latest init (apply)
• Dry-run output accurately previewed the file set, and the real run reported: 28 installed, 0 overwrote, 1 kept-customized.
• It preserved my existing AGENTS.md (marked CUSTOMIZED ... kept; rerun with --force to overwrite) instead of clobbering it.
• It detected sibling installs (claude-sdlc-wizard in .claude/, codex-sdlc-wizard in .codex/) and correctly noted .opencode/ coexists.
• It did not write opencode.json (backend selection is opt-in), so there was zero conflict with the config I hand-wrote.
• opencode debug config parsed/merged the final config with no errors; reasoningEffort: "xhigh" and textVerbosity: "low" survived the merge on both the plan and review agents.

Friction / questions

1. Zen has two different opencode provider shapes — this is the biggest doc gap.

   • .opencode/scripts/configure-backend.sh (tier managed/opencode) writes a custom OpenAI-compatible provider block: npm: "@ai-sdk/openai-compatible", baseURL: https://opencode.ai/zen/v1, apiKey: {env:OPENCODE_ZEN_API_KEY}.
   • But many users already have the built-in opencode (Zen) provider authenticated via OAuth/login (it shows up in auth.json as provider opencode, and opencode/<model> IDs resolve natively). That path needs no provider block and no env var — just enabled_providers: ["opencode"].
   • If a user on the built-in/OAuth path runs configure-backend.sh, they get a config that expects OPENCODE_ZEN_API_KEY, which they may not have set. Suggest documenting both paths and detecting which one is already active.

2. Model ID discovery. opencode models is the source of truth and worked great. Most guessed IDs matched exactly (opencode/gpt-5.5, opencode/claude-sonnet-4-6, opencode/deepseek-v4-flash, opencode/gpt-5.5-pro, opencode/gemini-3.5-flash, opencode/kimi-k2.6, opencode/big-pickle). Ambiguous ones worth calling out in a recipe: Claude Opus ships several (claude-opus-4-1/4-5/4-6/4-7/4-8) and Qwen ships qwen3.5-plus / qwen3.6-plus — a recipe should say "pick the newest" or pin explicitly.

3. reasoningEffort xhigh mechanism. Confirmed via docs that agent-level reasoningEffort + textVerbosity pass through as model options, and xhigh is a built-in OpenAI variant. This works for Zen's opencode/gpt-5.5. A short note in the wizard docs ("for xhigh planning/review, set reasoningEffort: "xhigh" on the agent, not a separate variant") would save time.

4. Permission shorthand vs. requirements. A naive "bash": "ask" on an agent neither allows safe commands nor denies destructive ones — it just prompts. To actually get "allow tests/lint/typecheck, deny git push/rm/reset --hard/clean", I used self-contained per-agent bash maps with explicit allow+deny rules (matching the docs example that restates rules per agent). A recipe should show this pattern rather than the shorthand.

5. Python repo defaults. The wizard's testing templates are great, but the permission examples skew toward npm/pnpm/yarn. For this Python/FastAPI repo I had to add pytest / ruff check / mypy (and .venv/bin/*) allow rules myself.

Suggested docs addition

Add a "Zen professional fallback profile" recipe page:

• Plan: GPT-5.5 xhigh (opencode/gpt-5.5, read-only — edit: deny)
• Build: Claude Sonnet 4.6 (opencode/claude-sonnet-4-6, edit: ask)
• Review: GPT-5.5 xhigh (opencode/gpt-5.5, subagent, read-only, merge-blocking)
• small_model: opencode/deepseek-v4-flash
• Emergency: GPT-5.5 Pro (opencode/gpt-5.5-pro) / Claude Opus (opencode/claude-opus-4-8)
• Cheap experiments: opencode/gemini-3.5-flash, opencode/kimi-k2.6, opencode/qwen3.6-plus, opencode/deepseek-v4-flash, opencode/big-pickle — with a privacy warning (free/experimental models: no proprietary/client code)
• enabled_providers: ["opencode"] for Zen-only isolation (call out built-in OAuth vs. env-key paths)
• Self-contained per-agent permission maps (allow safe tests/lint/typecheck, deny git push/rm/reset --hard/clean)
• Three simple commands (/plan-feature, /driver-task, /final-review) — explicitly no multi-agent swarm, just Plan -> Build -> Review.

Environment

• OpenCode: 1.16.2
• opencode-sdlc-wizard: 0.13.4
• OS: macOS 15.1 (24B83), arm64
• Node / npm: v25.9.0 / 11.12.1
• Zen model IDs available (opencode models): opencode/gpt-5.5, opencode/gpt-5.5-pro, opencode/claude-sonnet-4-6, opencode/claude-opus-4-8 (+ 4-1/4-5/4-6/4-7), opencode/deepseek-v4-flash (+ -free), opencode/gemini-3.5-flash, opencode/kimi-k2.6, opencode/qwen3.6-plus (+ qwen3.5-plus), opencode/big-pickle, plus the gpt-5.x / codex / glm / minimax / grok families.