merge: upstream kilocode v7.2.36

.changeset/quiet-ollamas-think.md

@@ -0,0 +1,5 @@
+---
+"@kilocode/cli": patch
+---
+
+Warn when a model hits its output limit before finishing a response.

.changeset/quiet-shields-remember.md

@@ -0,0 +1,5 @@
+---
+"kilo-code": patch
+---
+
+Remember the main auto-approve toggle preference across VS Code reloads and extension restarts.

.changeset/restore-mcp-oauth-sign-in.md

@@ -0,0 +1,6 @@
+---
+"kilo-code": patch
+"@kilocode/cli": patch
+---
+
+Restore the Sign in action for MCP servers that require OAuth authentication in VS Code settings.

.github/workflows/disabled/review.yml.disabled

@@ -49,13 +49,13 @@ jobs:
 
       - name: Check PR guidelines compliance
         env:
-          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
+          OPENCODE_API_KEY: ${{ secrets.OPENCODE_API_KEY }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           KILO_PERMISSION: '{ "bash": {  "*": "deny", "gh*": "allow", "gh pr review*": "deny" } }'
           PR_TITLE: ${{ steps.pr-details.outputs.title }}
         run: |
           PR_BODY=$(jq -r .body pr_data.json)
-          opencode run -m anthropic/claude-opus-4-5 "A new pull request has been created: '${PR_TITLE}'
+          opencode run -m opencode/gpt-5.5 --variant medium "A new pull request has been created: '${PR_TITLE}'
 
           <pr-number>
           ${{ steps.pr-number.outputs.number }}

.github/workflows/publish.yml

@@ -99,19 +99,20 @@ jobs:
       # download-artifact@v4's streaming unzip is CPU-bound and processes entries one by one;
       # collapsing ~480 files into one tar cuts build-vscode download from >30m to seconds.
       # zstd compresses the wasms (~4x) and leaves the already-compact binaries alone, for
-      # ~1 GB artifact. compression-level: 0 on the outer zip avoids double-compression.
-      # zstd + GNU tar are preinstalled on both github-hosted and blacksmith ubuntu-2404.
-      # See actions/upload-artifact#36, actions/toolkit#1533.
+      # ~1 GB artifact. upload-artifact@v7's `archive: false` skips the zip wrapper entirely
+      # so the tarball travels as-is (download-artifact@v8 auto-detects via Content-Type).
+      # With `archive: false` the `name:` input is ignored; the artifact is named after the
+      # file (kilo-cli.tar.zst). zstd + GNU tar are preinstalled on both github-hosted and
+      # blacksmith ubuntu-2404. See actions/upload-artifact#36, actions/toolkit#1533.
       - name: Pack CLI dist into tar.zst
         run: |
           find packages/opencode/dist -name '*.map' -delete
           tar --zstd -cf /tmp/kilo-cli.tar.zst -C packages/opencode/dist .
 
-      - uses: actions/upload-artifact@v4
+      - uses: actions/upload-artifact@v7
         with:
-          name: kilo-cli
           path: /tmp/kilo-cli.tar.zst
-          compression-level: 0
+          archive: false
       # kilocode_change end
 
     outputs:
@@ -135,10 +136,11 @@ jobs:
         run: bun install -g @vscode/vsce
 
       # kilocode_change start - download into /tmp and extract the tar.zst packed by build-cli
-      - uses: actions/download-artifact@v4
+      - uses: actions/download-artifact@v8
         with:
-          name: kilo-cli
+          name: kilo-cli.tar.zst
           path: /tmp
+          skip-decompress: true
 
       - name: Unpack CLI dist
         run: |
@@ -333,17 +335,18 @@ jobs:
           # kilocode_change end
 
       # kilocode_change start - download into /tmp and extract the tar.zst packed by build-cli
-      - uses: actions/download-artifact@v4
+      - uses: actions/download-artifact@v8
         with:
-          name: kilo-cli
+          name: kilo-cli.tar.zst
           path: /tmp
+          skip-decompress: true
 
       - name: Unpack CLI dist
         run: |
           mkdir -p packages/opencode/dist
           tar --zstd -xf /tmp/kilo-cli.tar.zst -C packages/opencode/dist
       # kilocode_change end
-      - uses: actions/download-artifact@v4
+      - uses: actions/download-artifact@v8
         with:
           name: kilo-vscode
           path: packages/kilo-vscode/out

.kilo/command/upstream-manual-merge.md

@@ -0,0 +1,71 @@
+---
+description: Resolve upstream merge conflicts with a reviewable decision ledger
+---
+
+Resolve the manual part of an upstream merge and preserve the decision process
+for PR review.
+
+Arguments: `$ARGUMENTS`
+
+Use the first argument as the upstream version, for example `v1.1.50` or
+`1.1.50`. If no argument is provided, infer the version from the newest
+`script/upstream/reports/manual-decisions-*.json` file or the current branch
+name.
+
+Workflow:
+
+1. Inspect the current merge state:
+   - `git status --short`
+   - `git diff --name-only --diff-filter=U`
+   - `script/upstream/reports/manual-decisions-<version>.md`
+   - `upstream-merge-report-<version>.md` when present
+   - `.worktrees/opencode-merge/auto-merge` for the automated merge snapshot when present
+2. If no decision ledger exists yet, run:
+   - `bun script/upstream/decisions.ts init --version <version>`
+3. Before editing, write a concise plan in the chat:
+   - file-by-file strategy
+   - expected decision kind: `hybrid`, `take-ours`, `take-theirs`, `regenerated`, `removed`, `renamed`, or `other`
+   - risk level: `low`, `medium`, or `high`
+   - verification commands you expect to run
+4. Resolve each conflict carefully:
+   - use `.worktrees/opencode-merge/opencode` as the pristine upstream reference when present
+   - use `.worktrees/opencode-merge/kilo-main` as the Kilo base reference when present
+   - use `.worktrees/opencode-merge/auto-merge` to inspect the original automated conflict when present
+   - use `script/upstream/find-conflict-markers.sh <file>` and `script/upstream/find-conflict-markers.sh .worktrees/opencode-merge/auto-merge/<file>` when the marker location is not obvious
+   - preserve Kilo-specific behavior marked with `kilocode_change`
+   - adopt upstream code and architecture whenever it does not conflict with Kilo behavior
+   - keep `kilocode_change` markers around Kilo-specific changes in shared opencode files
+   - maintain the same Kilo-specific text, code, and marker comments from the conflict snapshot unless refactoring is required
+   - if Kilo-specific code must be refactored to fit new upstream architecture, explain the refactor in the decision rationale
+   - if upstream moved the relevant logic to another file, port the Kilo behavior there and record the decision as `renamed` or `hybrid` with `--target <new-path>`
+   - if upstream deleted a file, analyze whether the Kilo behavior should be ported elsewhere or removed rather than restoring the deleted file
+   - if tests fail only because upstream intentionally removed behavior, remove or update the obsolete tests rather than adding the old file back
+   - do not modify unrelated files
+5. After resolving each file, record the decision before staging it:
+   - `bun script/upstream/decisions.ts add --version <version> --file <path> --kind <kind> --risk <risk> --summary "..." --rationale "..." --alternative "..." --verification "..."`
+   - the add command captures the resolved file snapshot; use `--resolution "..."` only when a file was deleted, renamed, generated, or too large to summarize automatically
+   - include at least one rejected alternative for non-trivial `hybrid`, `take-ours`, or `take-theirs` choices
+   - include `--target <new-path>` for `renamed` decisions
+   - use the rationale to explain why this preserves Kilo behavior while accepting the appropriate upstream change
+6. Run the appropriate checks:
+   - stage resolved files with `git add -A` before the ledger check so git no longer reports unmerged paths
+   - always run `bun script/upstream/decisions.ts check --version <version>`
+   - if `packages/opencode/` shared files changed, run `bun run script/check-opencode-annotations.ts`
+   - run targeted typechecks/tests when practical for touched packages
+7. Finish with:
+   - files resolved
+   - decisions recorded
+   - checks run and results
+   - any remaining high-risk areas for reviewer attention
+
+The generated markdown is the review artifact. For each manual file, ensure it
+contains the original diff3 conflict, the resolved content snapshot, the
+decision kind, summary, rationale, rejected alternatives, verification, and
+resolution hash. The PR body from `decisions.ts pr-body` should therefore let a
+reviewer compare the conflict with the resolution without reconstructing the
+agent session.
+
+Only ask the user before proceeding if a decision is destructive, changes auth,
+billing, data deletion, public API compatibility, config schema behavior,
+migrations, provider routing, or security posture in a way that cannot be
+safely inferred from the existing Kilo changes.

.kilo/skills/kilocode-merge-minimizer/SKILL.md

@@ -0,0 +1,119 @@
+---
+name: kilocode-merge-minimizer
+description: Use when changing shared upstream-owned files, editing or reviewing `kilocode_change` markers, or moving additive Kilo-specific behavior into Kilo-owned code to reduce future merge conflicts.
+---
+
+# Kilo Merge Minimizer
+
+Use this skill whenever a normal development task touches shared upstream-owned code and includes Kilo-specific behavior, especially for marker cleanup, extraction work, or `kilocode_change` annotations.
+
+Do not use this as the primary guide for upstream merge resolution. Upstream merges have their own instructions and should not duplicate that workflow here.
+
+## Goal
+
+Minimize Kilo's long-term diff against upstream OpenCode while preserving behavior.
+
+Prefer this shape for Kilo-specific additions:
+
+1. Shared upstream file contains only a minimal hook, import, call, registration, or config entry.
+2. Kilo-specific behavior lives in Kilo-owned code.
+3. Unavoidable shared-file changes have narrow `kilocode_change` markers.
+4. The annotation checker passes.
+
+For changes to existing upstream behavior, prefer the smallest in-place shared-file diff with narrow markers. Do not move changed upstream logic into Kilo-owned code just to avoid textual conflicts, because that can create harder semantic merge conflicts.
+
+## Core Rules
+
+- Use `script/check-opencode-annotations.ts` as the source of truth for current shared scopes and exempt paths.
+- Use `script/upstream/fix-kilocode-markers.ts` for stale or broad markers, inspecting `--dry-run` output before applying changes.
+- Treat upstream-owned files as shared unless the checker or repo ownership rules exempt them.
+- Put Kilo-owned UI, CLI, runtime logic, and tests in Kilo-owned paths where practical.
+- Avoid adding Kilo business logic directly to shared files.
+- Keep shared-file edits as close as possible to upstream shape.
+- Do not change shared files unless the change is required for Kilo functionality, fixes a Kilo bug, or is a minimal targeted upstream-quality fix.
+- Do not create a large Kilo-only fork for a general upstream-quality improvement. Prefer a minimal targeted fix, or leave the broader change for upstream.
+- Do not duplicate upstream logic unless there is a concrete reason. If duplication is unavoidable, isolate the Kilo delta and keep the upstream dependency obvious.
+
+## Shared File Structure
+
+- Do not refactor, rename, split files, or extract helpers in shared files just to improve readability or make Kilo extraction cleaner.
+- Avoid structural changes that make upstream behavior harder to compare or hide semantic dependency on upstream code.
+
+## Shared File Style
+
+- Preserve upstream formatting and import style in shared files, even when it differs from Kilo style.
+- Put Kilo-only imports on separate marked lines instead of reorganizing upstream imports.
+
+## Decision Rules
+
+Extract Kilo logic when:
+
+- The change is an additive Kilo feature or integration, not a modification of existing upstream behavior.
+- The shared-file change has meaningful Kilo-owned behavior, not just a tiny condition, import, registration, or field.
+- The code has loops, branching, error handling, async workflows, storage access, network calls, UI rendering, or telemetry.
+- The shared file can become a small orchestrator that calls Kilo helpers.
+- The Kilo code is independent enough that extraction will not hide future upstream fixes or behavior changes.
+
+Keep the change inline when:
+
+- The Kilo delta is a single field, import, call, simple condition, or small registry entry.
+- Extraction would reshape upstream code more than the Kilo change itself.
+- The change modifies an upstream algorithm, ordering, heuristic, control flow, or bug fix.
+- Extraction would duplicate upstream logic or hide semantic dependency on upstream behavior.
+- The Kilo helper closes over upstream-local state. Keep closure-scoped helpers inline and contiguous in one narrow marker block.
+- The shared file owns the only route table, enum, schema, switch, or registry where the hook must exist.
+- The change restores upstream shape or removes a stale Kilo divergence.
+
+Always preserve upstream behavior order unless the Kilo behavior change is intentional and tested.
+
+## Marker Rules
+
+- Mark only Kilo-specific diff lines in shared upstream files.
+- Prefer inline markers for single-line changes: `const value = 42 // kilocode_change`.
+- Use block markers only for adjacent Kilo-specific lines:
+
+```ts
+// kilocode_change start
+registerKiloFeature(app)
+// kilocode_change end
+```
+
+- Use the file's native comment style, including JSX block comments inside JSX and `#` comments for YAML, TOML, and shell.
+- Do not add markers in checker-exempt Kilo-owned paths.
+- Remove stale markers when upstream already contains the behavior or when touching Kilo-owned files that still have old markers.
+- Use `// kilocode_change - new file` only for unavoidable new Kilo-specific files inside shared upstream paths.
+
+## Tests
+
+- Put Kilo-specific CLI/runtime tests in Kilo-owned test paths.
+- Move tests out of shared upstream test paths when the behavior under test is Kilo-specific.
+- Tests should cover the real failing path, not private or unstable APIs chosen only for convenience.
+- Do not add skip gates for required regression coverage.
+
+## Verification
+
+After editing shared files or marker comments, run:
+
+```bash
+bun run script/check-opencode-annotations.ts
+```
+
+If the PR uses a non-default comparison base, pass the correct base ref:
+
+```bash
+bun run script/check-opencode-annotations.ts --base <base-ref>
+```
+
+For stale or broad markers in one shared file, inspect the dry run before applying:
+
+```bash
+bun run script/upstream/fix-kilocode-markers.ts <repo-relative-file> --dry-run
+```
+
+Before finishing, confirm:
+
+- Shared files contain minimal integration points only.
+- Kilo logic and tests live in Kilo-owned paths where practical.
+- Markers are narrow.
+- Stale markers are removed.
+- The annotation checker passed, or the reason it could not run is reported.

.opencode/skills/effect/SKILL.md

@@ -1,21 +1,30 @@
 ---
 name: effect
-description: Answer questions about the Effect framework
+description: Work with Effect v4 / effect-smol TypeScript code in this repo
 ---
 
 # Effect
 
-This codebase uses Effect, a framework for writing typescript.
+This codebase uses Effect for typed, composable TypeScript services, schemas, and workflows.
 
-## How to Answer Effect Questions
+## Source Of Truth
 
-1. Clone the Effect repository: `https://github.com/Effect-TS/effect-smol` to
-   `.opencode/references/effect-smol` in this project NOT the skill folder.
-2. Use the explore agent to search the codebase for answers about Effect patterns, APIs, and concepts
-3. Provide responses based on the actual Effect source code and documentation
+Use the current Effect v4 / effect-smol source, not memory or older Effect v2/v3 examples.
+
+1. If `.opencode/references/effect-smol` is missing, clone `https://github.com/Effect-TS/effect-smol` there. Do this in the project, not in the skill folder.
+2. Search `.opencode/references/effect-smol` for exact APIs, examples, tests, and naming patterns before answering or implementing Effect-specific code.
+3. Also inspect existing repo code for local house style before introducing new patterns.
+4. Prefer answers and implementations backed by specific source files or nearby repo examples.
 
 ## Guidelines
 
-- Always use the explore agent with the cloned repository when answering Effect-related questions
-- Reference specific files and patterns found in the Effect codebase
-- Do not answer from memory - always verify against the source
+- Prefer current Effect v4 APIs and project-local patterns over old blog posts, examples, or package-memory guesses.
+- Use `Effect.gen(function* () { ... })` for multi-step workflows.
+- Use `Effect.fn("Name")` or `Effect.fnUntraced(...)` for named effects when adding reusable service methods or important workflows.
+- Prefer Effect `Schema` for API and domain data shapes. Use branded schemas for IDs and `Schema.TaggedErrorClass` for typed domain errors when modeling new error surfaces.
+- Keep HTTP handlers thin: decode input, read request context, call services, and map transport errors. Put business rules in services.
+- In Effect service code, prefer Effect-aware platform abstractions and dependencies over ad hoc promises where the surrounding code already does so.
+- Keep layer composition explicit. Avoid broad hidden provisioning that makes missing dependencies hard to see.
+- In tests, prefer the repo's existing Effect test helpers and live tests for filesystem, git, child process, locks, or timing behavior.
+- Do not introduce `any`, non-null assertions, unchecked casts, or older Effect APIs just to satisfy types.
+- Do not answer from memory. Verify against `.opencode/references/effect-smol` or nearby code first.

.opencode/tool/github-triage.ts

@@ -3,8 +3,8 @@ import { tool } from "@kilocode/plugin"
 const TEAM = {
   desktop: ["adamdotdevin", "iamdavidhill", "Brendonovich", "nexxeln"],
   zen: ["fwang", "MrMushrooooom"],
-  tui: ["thdxr", "kommander", "rekram1-node"],
-  core: ["thdxr", "rekram1-node", "jlongster"],
+  tui: ["kommander", "rekram1-node", "simonklee"],
+  core: ["kitlangton", "rekram1-node", "jlongster"],
   docs: ["R44VC0RP"],
   windows: ["Hona"],
 } as const