OpenCode V1/V2 boundary documentation assumes a separate executable, but @opencode/cli 2.1.3 also exposes opencode #155

Observed on 2026-10-23 with LocalSetup 4.57.0, source commit 5d07ed278ed4c2030488013abbb1212de6e89844. The same relevant text was verified on current repository main.

Definition and documented boundary

• The opencode-cli profile registers executable opencode; its pinned upstream research is OpenCode 1.18.29.
• CLIENT_INTEGRATION_METADATA.md explicitly directs stable-V1 installation and says V2 beta uses a separate executable and is outside the profile.

Observed distribution and executable names

The current official V2 installation page offers:

bun install -g --trust @opencode/cli

An isolated installation pinned to @opencode/cli@2.1.3 succeeded on Linux x86_64 with Bun 1.4.4. Its installed package metadata contains:

{
  "name": "@opencode/cli",
  "version": "2.1.3",
  "bin": {
    "opencode": "./bin/opencode.exe",
    "opencode2": "./bin/opencode.exe"
  }
}

The package's opencode --version returned opencode v2.1.3, exit 0. Its --help describes the V2 CLI, including service, pair, reload, and mini. Official command documentation likewise invokes V2 as opencode.

The existing V1 opencode-ai@1.19.4 installation was retained separately; none of its files or configuration were migrated or replaced.

Reproduction and correction context

Install the exact V2 package into a disposable Bun global root/bin, inspect its package.json.bin, and run that root's opencode --version. Compare the result with the profile's executable candidate and its separate-executable statement.

The documentation's V1-only qualification boundary is useful, but executable name alone no longer distinguishes the supported implementation from V2. A user following the official V2 installer can have an executable matching opencode while LocalSetup's cited discovery/configuration evidence still concerns V1.

Please correct the executable/package/version boundary and make the current qualification scope explicit wherever installation guidance and profile selection meet. Any V2 path, precedence or host-loading qualification should have its own evidence rather than inherit the V1 evidence implicitly.

This report establishes distribution and identity/documentation drift. Only installation, package metadata, --version and --help were checked; it does not establish a failure of the V1 adapter or compatibility of that adapter with V2.