feat(jetbrains): add repo CLI dev mode - #12047
Conversation
Code Review SummaryStatus: 1 Issue Found | Recommendation: Address before merge (non-blocking) Overview
Issue Details (click to expand)SUGGESTION
Resolved since last review (incremental diff at this commit):
No new issues found in the incremental diff ( Files Reviewed (19 files)
Fix these issues in Kilo Cloud Previous Review Summaries (3 snapshots, latest commit 86a02bf)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 86a02bf)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Resolved since previous review:
Files Reviewed (19 files)
Fix these issues in Kilo Cloud Previous review (commit 616012e)Status: 5 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (17 files)
Fix these issues in Kilo Cloud Previous review (commit 98d8d22)Status: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (15 files)
Reviewed by claude-sonnet-5-20260630 · Input: 26 · Output: 7.8K · Cached: 603.3K Review guidance: REVIEW.md from base branch |
feat(jetbrains): add repo CLI dev mode
Summary
kilo.cli.pinned=falserepo CLI mode that generates the OpenAPI client from local repo source and stages the locally built CLI into backend resources.Why
JetBrains releases need to move independently from the CLI while still benefiting from the monorepo. A pinned CLI version lets us cut JetBrains-specific releases from a known, published CLI without accidentally taking unreleased or untested CLI/runtime changes. An unpinned repo mode lets us test cross-system work locally when the JetBrains plugin, generated SDK, and CLI/server need to evolve together.
This gives maintainers explicit options instead of one implicit coupling:
Scenarios
JetBrains-Specific Release
Use the pinned default (
kilo.cli.pinned=true) when releasing only JetBrains changes, such as IDE UI, split-mode integration, lifecycle fixes, or Marketplace packaging updates. The plugin downloads the published CLI version frompackages/kilo-jetbrains/package.json, and release checks verify that the pinned CLI release/assets exist before tagging.Ask the agent:
Cross-System Feature Work
Use repo CLI mode (
kilo.cli.pinned=false) for local development when a feature needs coordinated changes across the JetBrains plugin and the CLI/server API. In this mode OpenAPI generation runs from localpackages/opencode/, and the local CLI build is bundled into backend resources for runtime testing.Ask the agent:
OpenCode Merge Validation
Use repo CLI mode to validate upstream/OpenCode merge work that may affect generated API types, server routes, process behavior, or bundled CLI assets before a CLI release exists. This makes it possible to test the JetBrains plugin against the merged repo state without publishing a temporary CLI.
Ask the agent:
Returning To Release Mode
Before publishing or preparing a JetBrains release, restore
kilo.cli.pinned=true. Gradle production builds, release scripts, and the JetBrains release skill reject repo CLI mode so local test binaries cannot be shipped accidentally.Ask the agent:
CLI Release Follow-Up
Stable CLI releases now leave the JetBrains CLI pin as a reviewed follow-up instead of silently changing it in the CLI release commit. After the CLI publish flow completes, it attempts to open or update a PR that bumps
packages/kilo-jetbrains/package.jsonto the newly released CLI version.That follow-up PR:
jetbrains-cli-pin-bump.jetbrains/v*tag.Notes
:backend:buildRepoCliinstead of auto-building.bin/directory so tree-sitter assets, console files, sandbox workers, and Linuxbwrapstay available.Release Analysis