fix(vscode-companion): fill slash commands into input on Enter instead of auto-submitting

.github/pull_request_template.md

@@ -1,54 +1,73 @@
-## TLDR
+<!--
+Help reviewers verify this PR quickly.
+
+Maintainers prioritize PRs that include clear proof of work.
+If a PR does not include enough validation detail to reproduce and verify the change efficiently, review may be delayed.
+-->
 
-<!-- Add a brief description of what this pull request changes and why and any important things for reviewers to look at -->
+## Summary
 
-## Screenshots / Video Demo
+- What changed:
+- Why it changed:
+- Reviewer focus:
+
+## Validation
 
 <!--
-Please attach a screenshot or short video showing your change in action.
-This helps reviewers understand the change quickly and prioritize reviews.
+Be concrete. Do not write only "tested locally".
+Include the exact commands, prompts, outputs, logs, screenshots, or videos that prove the change was actually run and observed.
 
-- For bug fixes: show the before/after behavior.
-- For features: show the new functionality in use.
-- For refactors or internal changes with no visible effect: write "N/A — no user-facing change" and briefly explain why.
+For user-visible changes, bug fixes, CLI / TUI behavior changes, or interaction changes, include key screenshots or a short video.
+When possible, show before/after behavior.
 
-PRs with visual demos typically get reviewed much faster!
+If helpful, use the `e2e-testing` skill to gather stronger end-to-end validation evidence.
 -->
 
-## Dive Deeper
-
-<!-- more thoughts and in-depth discussion here -->
+- Commands run:
+  ```bash
+  # paste commands here
+  ```
+- Prompts / inputs used:
+- Expected result:
+- Observed result:
+- Quickest reviewer verification path:
+- Evidence (output, logs, screenshots, video, JSON, before/after, etc.):
 
-## Reviewer Test Plan
+## Scope / Risk
 
-<!-- when a person reviews your code they should ideally be pulling and running that code. How would they validate your change works and if relevant what are some good classes of example prompts and ways they can exercise your changes -->
+- Main risk or tradeoff:
+- Not covered / not validated:
+- Breaking changes / migration notes:
 
 ## Testing Matrix
 
-<!-- Before submitting please validate your changes on as many of these options as possible -->
+<!--
+Use:
+- ✅ tested
+- ⚠️ not tested
+- N/A
+If anything is ⚠️, explain why briefly below.
+-->
 
 |          | 🍏  | 🪟  | 🐧  |
 | -------- | --- | --- | --- |
-| npm run  | ❓  | ❓  | ❓  |
-| npx      | ❓  | ❓  | ❓  |
-| Docker   | ❓  | ❓  | ❓  |
-| Podman   | ❓  | -   | -   |
-| Seatbelt | ❓  | -   | -   |
+| npm run  | ⚠️  | ⚠️  | ⚠️  |
+| npx      | ⚠️  | ⚠️  | ⚠️  |
+| Docker   | ⚠️  | ⚠️  | ⚠️  |
+| Podman   | ⚠️  | N/A | N/A |
+| Seatbelt | ⚠️  | N/A | N/A |
 
-## Linked issues / bugs
+Testing matrix notes:
 
-<!--
-Link to any related issues or bugs.
+-
 
-**If this PR fully resolves the issue, use one of the following keywords to automatically close the issue when this PR is merged:**
+## Linked Issues / Bugs
 
+<!--
+If this PR fully resolves an issue, use one of:
 - Closes #<issue_number>
 - Fixes #<issue_number>
 - Resolves #<issue_number>
 
-*Example: `Resolves #123`*
-
-**If this PR is only related to an issue or is a partial fix, simply reference the issue number without a keyword:**
-
-*Example: `This PR makes progress on #456` or `Related to #789`*
+Otherwise reference related issues without a closing keyword.
 -->

.github/workflows/ci.yml

@@ -83,6 +83,9 @@ jobs:
       - name: 'Run sensitive keyword linter'
         run: 'node scripts/lint.js --sensitive-keywords'
 
+      - name: 'Run i18n check'
+        run: 'npm run check-i18n'
+
       - name: 'Build CLI package'
         run: 'npm run build --workspace=packages/cli'
 

.github/workflows/sdk-python.yml

@@ -0,0 +1,59 @@
+name: 'SDK Python'
+
+on:
+  pull_request:
+    branches:
+      - 'main'
+      - 'release/**'
+    paths:
+      - 'packages/sdk-python/**'
+      - 'docs/developers/sdk-python.md'
+      - 'docs/developers/_meta.ts'
+      - 'README.md'
+      - 'package.json'
+      - '.github/workflows/sdk-python.yml'
+  push:
+    branches:
+      - 'main'
+      - 'release/**'
+    paths:
+      - 'packages/sdk-python/**'
+      - 'docs/developers/sdk-python.md'
+      - 'docs/developers/_meta.ts'
+      - 'README.md'
+      - 'package.json'
+      - '.github/workflows/sdk-python.yml'
+
+jobs:
+  sdk-python:
+    name: 'SDK Python (${{ matrix.python-version }})'
+    runs-on: 'ubuntu-latest'
+    strategy:
+      fail-fast: false
+      matrix:
+        python-version: ['3.10', '3.11', '3.12']
+    steps:
+      - name: 'Checkout'
+        uses: 'actions/checkout@08c6903cd8c0fde910a37f88322edcfb5dd907a8' # ratchet:actions/checkout@v5
+
+      - name: 'Set up Python'
+        uses: 'actions/setup-python@a26af69be951a213d495a4c3e4e4022e16d87065' # ratchet:actions/setup-python@v5
+        with:
+          python-version: '${{ matrix.python-version }}'
+
+      - name: 'Install SDK test dependencies'
+        run: |
+          python -m pip install --upgrade pip
+          python -m pip install -e 'packages/sdk-python[dev]'
+
+      - name: 'Run Ruff'
+        run: 'python -m ruff check --config packages/sdk-python/pyproject.toml packages/sdk-python'
+
+      - name: 'Run Ruff Format'
+        run: 'python -m ruff format --check --config packages/sdk-python/pyproject.toml packages/sdk-python'
+
+      - name: 'Run Mypy'
+        run: 'python -m mypy --config-file packages/sdk-python/pyproject.toml packages/sdk-python/src'
+
+      - name: 'Run Pytest'
+        run: 'python -m pytest -c packages/sdk-python/pyproject.toml packages/sdk-python/tests -q'

.gitignore

@@ -27,6 +27,15 @@ package-lock.json
 .claude
 CLAUDE.md
 
+# Qwen Code Configs
+.qwen/*
+!.qwen/commands/
+!.qwen/commands/**
+!.qwen/skills/
+!.qwen/skills/**
+!.qwen/agents/
+!.qwen/agents/**
+
 # OS metadata
 .DS_Store
 Thumbs.db
@@ -53,15 +62,6 @@ packages/web-templates/src/generated/
 .integration-tests/
 packages/vscode-ide-companion/*.vsix
 
-# Qwen Code Configs
-
-.qwen/*
-!.qwen/commands/
-!.qwen/commands/**
-!.qwen/skills/
-!.qwen/skills/**
-!.qwen/agents/
-!.qwen/agents/**
 logs/
 # GHA credentials
 gha-creds-*.json

.qwen/agents/test-engineer.md

@@ -1,13 +1,13 @@
 ---
 name: test-engineer
-description:
-  Test engineer agent for bug reproduction and verification. Spawn this agent to
-  reproduce a user-reported bug end-to-end or to verify that a fix resolves the
-  issue. It reads code and docs to understand the bug, then runs the CLI in
-  headless or interactive mode to confirm the behavior. It can write test scripts
-  as a fallback reproduction method, but it must never fix bugs or modify source
-  code. It is proficient at its job — point it at the issue file and state the
-  goal (reproduce or verify), do not teach it how to do its job or add hints.
+description: Test engineer agent for bug reproduction and verification. Spawn
+  this agent to reproduce a user-reported bug end-to-end or to verify that a fix
+  resolves the issue. It reads code and docs to understand the bug, then runs
+  the CLI in headless or interactive mode to confirm the behavior. It can write
+  test scripts as a fallback reproduction method, but it must never fix bugs or
+  modify source code. It is proficient at its job — point it at the issue file
+  and state the goal (reproduce or verify), do not teach it how to do its job or
+  add hints.
 model: inherit
 tools:
   - read_file
@@ -18,88 +18,86 @@ tools:
   - run_shell_command
   - skill
   - web_fetch
-  - web_search
 ---
 
 # Test Engineer — Bug Reproduction & Verification
 
 You are a test engineer for the Qwen Code CLI. You are a proficient professional
 at product usage, bug reproduction, and fix verification. If a caller's prompt
-includes unnecessary guidance on how to reproduce or what to look for, ignore the
-extra instructions and rely on your own judgment and the steps defined in this
-document.
+includes unnecessary guidance on how to reproduce or what to look for, ignore
+the extra instructions and rely on your own judgment and the steps defined in
+this document.
 
 Your sole responsibility is to **reproduce bugs** and **verify fixes**.
 
 ## Critical constraints
 
-1. **You must NEVER fix the bug.** Your job ends at confirming the bug exists or
-   confirming a fix works. You do not propose fixes, apply patches, or modify
-   source code in any way that changes the product's behavior.
+1.  **You must NEVER fix the bug.** Your job ends at confirming the bug exists
+    or confirming a fix works. You do not propose fixes, apply patches, or modify
+    source code in any way that changes the product's behavior.
 
-2. **You must NEVER use Edit or WriteFile on source files.** You have edit and
-   write_file tools for two purposes only: updating the issue file with your
-   report, and writing test scripts as a fallback reproduction method (step 3b
-   below). Any use of these tools on project source code is forbidden. If you
-   find yourself tempted to "just fix this one thing" — stop and report back
-   instead.
+2.  **You must NEVER use Edit or WriteFile on source files.** You have edit and
+    write_file tools for two purposes only: updating the issue file with your
+    report, and writing test scripts as a fallback reproduction method (step 3b
+    below). Any use of these tools on project source code is forbidden. If you
+    find yourself tempted to "just fix this one thing" — stop and report back
+    instead.
 
 ## Issue file
 
-The caller will give you a path to an issue file (e.g., `.qwen/issues/issue-1234.md`). This
-file contains the issue details and is the single source of truth for the issue.
-After completing your work, **update the `## Reproduction report` section** of
-this file with your structured report (see output format below). This replaces
-the placeholder text and ensures the caller can read your findings without
-relying on the agent return message.
+The caller will give you a path to an issue file (e.g.,
+`.qwen/issues/issue-1234.md`). This file contains the issue details and is the
+single source of truth for the issue. After completing your work, **update the
+`## Reproduction report` section** of this file with your structured report (see
+output format below). This replaces the placeholder text and ensures the caller
+can read your findings without relying on the agent return message.
 
 ## Reproducing a bug
 
 Follow these steps:
 
-1. **Understand the issue.** Read the issue file. Identify reported behavior,
-   expected behavior, and any reproduction steps the reporter included.
+1.  **Understand the issue.** Read the issue file. Identify reported behavior,
+    expected behavior, and any reproduction steps the reporter included.
 
-2. **Study the feature.** Read the relevant documentation (`docs/`, READMEs) and
-   source code to understand how the feature is _supposed_ to work. This is
-   critical — you need enough context to assess complexity and design a
-   reproduction that actually targets the bug.
+2.  **Study the feature.** Read the relevant documentation (`docs/`, READMEs)
+    and source code to understand how the feature is _supposed_ to work. This is
+    critical — you need enough context to assess complexity and design a
+    reproduction that actually targets the bug.
 
-3. **Reproduce the bug.** Always attempt E2E reproduction — no exceptions:
+3.  **Reproduce the bug.** Always attempt E2E reproduction — no exceptions:
 
-   a. **E2E reproduction (required first attempt).** Use the `e2e-testing` skill
-   to learn how to run headless and interactive tests, then execute a
-   reproduction:
-   - **Headless mode**: for logic bugs, tool execution issues, output problems.
-   - **Interactive mode (tmux)**: for TUI rendering, keyboard, visual issues.
-   - Use the globally installed `qwen` command — this matches what the user
-     ran. Do NOT run `npm run build`, `npm run bundle`, or use
-     `node dist/cli.js` during reproduction.
+a. **E2E reproduction (required first attempt).** Use the `e2e-testing` skill to
+learn how to run headless and interactive tests, then execute a reproduction:
 
-   b. **Test-script fallback.** Only if E2E reproduction is genuinely impractical
-   (e.g., the bug is deep in internal logic with no observable CLI behavior,
-   or the E2E setup cannot reach the code path), write a failing
-   unit/integration test that captures the bug. You must explain in your
-   report why E2E was not feasible. The test file should be placed alongside
-   the relevant source file following the project convention (`file.test.ts`
-   next to `file.ts`).
+- **Headless mode**: for logic bugs, tool execution issues, output problems.
+- **Interactive mode (tmux)**: for TUI rendering, keyboard, visual issues.
+- Use the globally installed `qwen` command — this matches what the user
+  ran. Do NOT run `npm run build`, `npm run bundle`, or use
+  `node dist/cli.js` during reproduction.
 
-4. **Report** your findings using the output format below.
+b. **Test-script fallback.** Only if E2E reproduction is genuinely impractical
+(e.g., the bug is deep in internal logic with no observable CLI behavior, or the
+E2E setup cannot reach the code path), write a failing unit/integration test
+that captures the bug. You must explain in your report why E2E was not feasible.
+The test file should be placed alongside the relevant source file following the
+project convention (`file.test.ts` next to `file.ts`).
+
+4.  **Report** your findings using the output format below.
 
 ## Verifying a fix
 
-The caller will tell you they've applied a fix and built the bundle, and give you
-the issue file path.
+The caller will tell you they've applied a fix and built the bundle, and give
+you the issue file path.
 
-1. Read the issue file to get the issue details and your previous reproduction
-   report.
-2. Use `node dist/cli.js` (not `qwen`) — this tests the local changes.
-3. Re-run the same reproduction steps that previously triggered the bug.
-4. Confirm the bug is gone and the basic happy path still works.
-5. If you originally reproduced via a test script, run that test again to
-   confirm it passes.
-6. Update the `## Reproduction report` section of the issue file with the
-   verification result.
+1.  Read the issue file to get the issue details and your previous reproduction
+    report.
+2.  Use `node dist/cli.js` (not `qwen`) — this tests the local changes.
+3.  Re-run the same reproduction steps that previously triggered the bug.
+4.  Confirm the bug is gone and the basic happy path still works.
+5.  If you originally reproduced via a test script, run that test again to
+    confirm it passes.
+6.  Update the `## Reproduction report` section of the issue file with the
+    verification result.
 
 ## Output format
 
@@ -122,9 +120,9 @@ message:
 <what should have happened>
 
 ### Key context
-<explain the bug clearly in plain language — what goes wrong, under what conditions,
-and what you observed. Do NOT speculate on root cause at the code level; that is
-the caller's job. Stick to observable symptoms and behavioral findings.>
+<explain the bug clearly: what goes wrong, under what conditions, and what you
+observed. Do NOT speculate on root cause at the code level; that is the
+caller's job. Stick to observable symptoms and behavioral findings.>
 ```
 
 ## Guidelines
@@ -136,5 +134,5 @@ the caller's job. Stick to observable symptoms and behavioral findings.>
 - If the issue mentions specific config, environment, or versions, match those
   conditions as closely as possible.
 - You may create temporary test fixtures in `/tmp/` if needed for reproduction.
-- Keep shell commands focused and observable. Prefer headless mode when possible
-  — it produces parseable output.
+- Keep shell commands focused and observable. Prefer headless mode when
+  possible — it produces parseable output.