feat: improve Kilo Console worktree review

[catrielmuller]

Issue

No linked issue; this is a scoped Kilo Console UI improvement.

Context

Improve project worktree management and review inside Kilo Console. Native browser prompts and raw patch output made routine worktree actions feel disconnected from the rest of the console and made larger diffs difficult to inspect.

Implementation

Worktree create, rename, reset, and delete actions now use accessible console dialogs. The project details area uses the shared session review UI with lazy per-file diff loading, syntax highlighting, unified/split layouts, and a resizable sidebar. Global Console UI settings persist the default sidebar width and diff layout through the CLI config schema and generated SDK.

Screenshots / Video

How to Test

Manual/local verification

• Agent: bun run typecheck in packages/kilo-console passed.
• Agent: bun test src/routes/config/state/console.test.ts in packages/kilo-console passed (3 tests).
• Agent: bun run typecheck in packages/opencode passed.
• Agent: bun test test/kilocode/config/console-ui.test.ts in packages/opencode passed (2 tests).
• Agent: the pre-push hook ran bun turbo typecheck successfully across 17 tasks.
• Agent: bun run script/check-opencode-annotations.ts passed.

Reviewer test steps

1. Run bun dev -- console and open Global Settings > Console > UI.
2. Change the project context sidebar width and diff layout, save, and confirm the values persist after reload.
3. Open a project worktree with changed files, expand files in Changes, and confirm syntax-highlighted unified and split diffs render correctly.
4. Drag the context sidebar edge and confirm its width persists.
5. Create, rename, reset, and delete a worktree and confirm each action uses the in-app dialog flow.

Checklist

• Issue linked above, or exception explained
• Tests/verification described
• Screenshots/video included for visual changes, or marked N/A
• Changeset considered for user-facing changes
• I personally reviewed the diff and can explain the changes, including any AI-assisted work.

[kilo-code-bot]

WARNING: resize.timer is not cleared in onCleanup, but events.timer is. If the component unmounts while a resize debounce is in flight, the setTimeout callback will fire after cleanup and call patchConfig with stale closure data.

Add if (resize.timer) window.clearTimeout(resize.timer) here alongside the events.timer cleanup.

[kilo-code-bot]

SUGGESTION: The generated type includes duplicate and semantically misleading string literals: number | "NaN" | "Infinity" | "-Infinity" | "Infinity" | "-Infinity" | "NaN". The duplicates ("Infinity", "-Infinity", "NaN" appear twice each) are a code-gen artifact from Effect's Schema.Number union with its special-value serialization.

Since Config.Info uses Schema.Number.check(isGreaterThanOrEqualTo(250), isLessThanOrEqualTo(800)) which effectively rejects NaN and Infinity at runtime anyway, consider wrapping the schema with Schema.Int or Schema.Finite so the codegen produces a clean number type here. Otherwise this is cosmetic — it won't cause a runtime bug.

[kilo-code-bot]

Code Review Summary

Status: No Issues Found | Recommendation: Merge

All previous issues remain resolved. The sole change since eb4d2e6 (refactor: fix kilo marker) adds a // kilocode_change annotation to the getSharedHighlighter import in packages/ui/src/context/marked.tsx — a correct marker for a Kilo-specific import in a shared upstream file. No logic was altered.

Files Reviewed (1 file, incremental)

• packages/ui/src/context/marked.tsx — marker annotation only, no issues

---

_{Reviewed by claude-4.6-sonnet-20260217 · 176,856 tokens}

_{Review guidance: REVIEW.md from base branch main}

[marius-kilocode]

I wonder if we should rather have a common kilo diff logic that is being reused here. This primarily uses the OpenCode components. What is the reasoning behind this?

[catrielmuller]

I wonder if we should rather have a common kilo diff logic that is being reused here. This primarily uses the OpenCode components. What is the reasoning behind this?

Hey @marius-kilocode , I'm utilizing the shared components as-is. I am unclear about the diff logic you mentioned, because the diff comes from the SDK and the UI comes from the UI library