Merge remote main into fix/pdf-session-corruption

Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>

.qwen/commands/qc/code-review.md

@@ -0,0 +1,26 @@
+---
+description: Code review a pull request
+---
+
+You are an expert code reviewer. Follow these steps:
+
+1. If no PR number is provided in the args, use Bash(\"gh pr list\") to show open PRs
+2. If a PR number is provided, use Bash(\"gh pr view <number>\") to get PR details
+3. Use Bash(\"gh pr diff <number>\") to get the diff
+4. Analyze the changes and provide a thorough code review that includes:
+   - Overview of what the PR does
+   - Analysis of code quality and style
+   - Specific suggestions for improvements
+   - Any potential issues or risks
+
+Keep your review concise but thorough. Focus on:
+
+- Code correctness
+- Following project conventions
+- Performance implications
+- Test coverage
+- Security considerations
+
+Format your review with clear sections and bullet points.
+
+PR number: {{args}}

.qwen/commands/qc/commit.md

@@ -0,0 +1,79 @@
+---
+description: Commit staged changes with an AI-generated commit message and push
+---
+
+# Commit and Push
+
+## Overview
+
+Generate a clear, concise commit message based on staged changes, confirm with the user, then commit and push.
+
+## Steps
+
+### 1. Check repository status
+
+- Run `git status` to check:
+  - Are there any staged changes?
+  - Are there unstaged changes?
+  - What is the current branch?
+
+### 2. Handle unstaged changes
+
+- If there are unstaged changes, notify the user and list them
+- Do NOT add or commit unstaged changes
+- Proceed only with staged changes
+
+### 3. Review staged changes
+
+- Run `git diff --staged` to see all staged changes
+- Analyze the changes in depth to understand:
+  - What files were modified/added/deleted
+  - The nature of the changes (feature, fix, refactor, docs, etc.)
+  - The scope and impact of the changes
+
+### 4. Handle branch logic
+
+- Get current branch name with `git branch --show-current`
+- **If current branch is `main` or `master`:**
+  - Generate a proper branch name based on the changes
+  - Create and switch to the new branch: `git checkout -b <branch-name>`
+- **If current branch is NOT main/master:**
+  - Check if branch name matches the staged changes
+  - If branch name doesn't match changes, ask user:
+    - "Current branch `<branch>` doesn't seem to match these changes."
+    - "Options: (1) Create and switch to a new branch, (2) Commit directly on current branch"
+    - Wait for user decision
+
+### 5. Generate commit message
+
+- Types: feat, fix, docs, style, refactor, test, chore
+- Guidelines:
+  - Be clear and concise
+  - Reference issues if mentioned in changes
+  - Include scope in parentheses when applicable (e.g., `fix(insight):`, `feat(auth):`)
+  - Add bullet points for detailed changes if it addes more value, otherwise do not use bullets
+  - Include a footer explaining the purpose/impact of the changes
+
+**Format:**
+
+```
+<type>(<scope>): <short description>
+- <detail point 1> (optional)
+- <detail point 2> (optional)
+- ...
+
+This <explains the why/impact of the changes>.
+```
+
+### 6. Present the result and confirm with user
+
+- Present the generated commit message
+- Show which branch will be used
+- Ask for confirmation: "Proceed with commit and push?"
+- Wait for user approval
+
+### 7. Commit and push
+
+- After user confirms:
+  - `git commit -m "<commit-message>"`
+  - `git push -u origin <branch-name>` (use `-u` for new branches)

.qwen/commands/qc/create-issue.md

@@ -0,0 +1,44 @@
+---
+description: Draft and submit a GitHub issue based on a user-provided idea
+---
+
+# Create Issue
+
+## Overview
+
+Take the user's idea or bug description, investigate the codebase to understand the full context, draft a GitHub issue for review, and submit it once approved.
+
+## Input
+
+The user provides a brief description of a feature request or bug report: {{args}}
+
+## Steps
+
+1. **Understand the request**
+   - Read the user's description carefully
+   - Determine whether this is a feature request or a bug report
+
+2. **Investigate the codebase**
+   - Search for relevant code, files, and existing behavior related to the request
+   - Build a thorough understanding of how the current system works
+   - Identify any related issues or prior art if mentioned
+
+3. **Draft the issue**
+   - Write a markdown file for the user to review
+   - Use the appropriate template:
+     - Feature request: follow @.github/ISSUE_TEMPLATE/feature_request.yml
+     - Bug report: follow @.github/ISSUE_TEMPLATE/bug_report.yml
+   - Write from the user's perspective, not as an implementation spec
+   - Keep the language clear and concise, AVOID internal implementation details
+
+4. **Review with user**
+   - Present the draft file to the user
+   - Iterate on feedback until the user is satisfied
+   - Do NOT submit until the user explicitly asks to
+
+5. **Submit the issue**
+   - When the user confirms, create the issue using `gh issue create`
+   - Apply the appropriate labels:
+     - Feature request: `type/feature-request`, `status/needs-triage`
+     - Bug report: `type/bug`, `status/needs-triage`
+   - Report back the issue URL

.qwen/commands/qc/create-pr.md

@@ -0,0 +1,36 @@
+---
+description: Create a pull request based on staged code changes
+---
+
+# Create PR
+
+## Overview
+
+Create a well-structured pull request with proper description and title.
+
+## Steps
+
+1. **Review staged changes**
+   - Review all staged changes to understand what has been done
+   - Do not touch unstaged changes
+
+2. **Prepare branch**
+   - Create a new branch with proper name if current branch is main
+   - Ensure all changes are committed
+   - Push branch to remote
+
+3. **Write PR description**
+   - Use PR Template below
+   - Summarize changes clearly
+   - Include context and motivation
+   - List any breaking changes
+   - Link related issues if provided, or use "No linked issues"
+   - Add this line at the end of PR body: "🤖 Generated with [Qwen Code](https://github.com/QwenLM/qwen-code)", with a line separator
+
+4. **Set up PR**
+   - Create PR title and body
+   - Submit PR with gh command
+
+## PR Template
+
+@{.github/pull_request_template.md}

.qwen/skills/docs-audit-and-refresh/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: docs-audit-and-refresh
+description: Audit the repository's docs/ content against the current codebase, find missing, incorrect, or stale documentation, and refresh the affected pages. Use when the user asks to review docs coverage, find outdated docs, compare docs with the current repo, or fix documentation drift across features, settings, tools, or integrations.
+---
+
+# Docs Audit And Refresh
+
+## Overview
+
+Audit `docs/` from the repository outward: inspect the current implementation, identify documentation gaps or inaccuracies, and update the relevant pages. Keep the work inside `docs/` and treat code, tests, and current configuration surfaces as the authoritative source.
+
+Read [references/audit-checklist.md](references/audit-checklist.md) before a broad audit so the scan stays focused on high-signal areas.
+
+## Workflow
+
+### 1. Build a current-state inventory
+
+Inspect the repository areas that define user-facing or developer-facing behavior.
+
+- Read the relevant code, tests, schemas, and package surfaces.
+- Focus on shipped behavior, stable configuration, exposed commands, integrations, and developer workflows.
+- Use the existing docs tree as a map of intended coverage, not as proof that coverage is complete.
+
+### 2. Compare implementation against `docs/`
+
+Look for three classes of issues:
+
+- Missing documentation for an existing feature, setting, tool, or workflow
+- Incorrect documentation that contradicts the current codebase
+- Stale documentation that uses old names, defaults, paths, or examples
+
+Prefer proving a gap with repository evidence before editing. Use current code and tests instead of intuition.
+
+### 3. Prioritize by reader impact
+
+Fix the highest-cost issues first:
+
+1. Broken onboarding, setup, auth, installation, or command flows
+2. Wrong settings, defaults, paths, or feature behavior
+3. Entirely missing documentation for a real surface area
+4. Lower-impact clarity or organization improvements
+
+### 4. Refresh the docs
+
+Update the smallest correct set of pages under `docs/`.
+
+- Edit existing pages first
+- Add new pages only for clear, durable gaps
+- Update the nearest `_meta.ts` when adding or moving pages
+- Keep examples executable and aligned with the current repository structure
+- Remove dead or misleading text instead of layering warnings on top
+
+### 5. Validate the refresh
+
+Before finishing:
+
+- Search `docs/` for old terminology and replaced config keys
+- Check neighboring pages for conflicting guidance
+- Confirm new pages appear in the right `_meta.ts`
+- Re-read critical examples, commands, and paths against code or tests
+
+## Audit standards
+
+- Favor breadth-first discovery, then depth on confirmed gaps.
+- Do not rewrite large areas without evidence that they are wrong or missing.
+- Keep README files out of scope for edits; limit changes to `docs/`.
+- Call out residual gaps if the audit finds issues that are too large to solve in one pass.
+
+## Deliverable
+
+Produce a focused docs refresh that makes the current repository more accurate and complete. Summarize the audited surfaces and the concrete pages updated.

.qwen/skills/docs-audit-and-refresh/references/audit-checklist.md

@@ -0,0 +1,41 @@
+# Audit Checklist
+
+Use this checklist to keep repository-wide documentation audits focused and repeatable.
+
+## High-signal repository surfaces
+
+- `packages/cli/**`
+  Inspect commands, flows, prompts, flags, and CLI-facing behavior.
+- `packages/core/**`
+  Inspect shared behavior, settings, tools, provider integration, and feature semantics.
+- `packages/sdk-typescript/**` and `packages/sdk-java/**`
+  Inspect SDK setup, usage, and examples that may affect developer docs.
+- `packages/vscode-ide-companion/**`, `packages/zed-extension/**`, and related integration packages
+  Inspect IDE and extension behavior that should be reflected in user docs.
+- `docs/**/_meta.ts`
+  Inspect navigation completeness after creating or moving pages.
+
+## Gap detection prompts
+
+Ask these questions while comparing the repo to `docs/`:
+
+- Does a visible feature exist in code but have no page or section in `docs/`?
+- Does a docs page mention a command, setting, provider, or path that no longer exists?
+- Do examples still match the current repository layout and command syntax?
+- Is a page present but hidden or missing from `_meta.ts`?
+- Do multiple pages describe the same feature inconsistently?
+
+## Common drift patterns
+
+- Renamed settings keys or changed defaults
+- Updated authentication or provider configuration flow
+- New or removed CLI commands and flags
+- New tool behavior or approval/sandbox semantics
+- IDE integration changes that never reached the docs
+- Features documented in the wrong section, making them hard to find
+
+## Output standard
+
+- Prefer a small number of precise edits over a speculative docs rewrite.
+- Leave a clear summary of what was missing, wrong, or stale.
+- If the audit uncovers a larger docs reorganization, fix the highest-impact inaccuracies first and note the remaining work.

.qwen/skills/docs-update-from-diff/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: docs-update-from-diff
+description: Review local code changes with git diff and update the official docs under docs/ to match. Use when the user asks to document current uncommitted work, sync docs with local changes, update docs after a feature or refactor, or when phrases like "git diff", "local changes", "update docs", or "official docs" appear.
+---
+
+# Docs Update From Diff
+
+## Overview
+
+Inspect local diffs, derive the documentation impact, and update only the repository's `docs/` pages. Treat the current code as the source of truth and keep changes scoped, specific, and navigable.
+
+Read [references/docs-surface.md](references/docs-surface.md) before editing if the affected feature does not map cleanly to an existing docs section.
+
+## Workflow
+
+### 1. Build the change set
+
+Start from local Git state, not from assumptions.
+
+- Inspect `git status --short`, `git diff --stat`, and targeted `git diff` output.
+- Focus on non-doc changes first so the documentation delta is grounded in code.
+- Ignore `README.md` and other non-`docs/` content unless they help confirm intent.
+
+### 2. Derive the docs impact
+
+For every changed behavior, extract the user-facing or developer-facing facts that documentation must reflect.
+
+- New command, flag, config key, default, workflow, or limitation
+- Renamed behavior or removed behavior
+- Changed examples, paths, or setup steps
+- New feature that belongs in an existing page but is not mentioned yet
+
+Prefer updating an existing page over creating a new page. Create a new page only when the feature introduces a stable topic that would make an existing page harder to follow.
+
+### 3. Find the right docs location
+
+Map each change to the smallest correct documentation surface:
+
+- End-user behavior: `docs/users/**`
+- Developer internals, SDKs, contributor workflow, tooling: `docs/developers/**`
+- Shared landing or navigation changes: root `docs/**` and `_meta.ts`
+
+If you add a new page, update the nearest `_meta.ts` in the same docs section so the page is discoverable.
+
+### 4. Write the update
+
+Edit documentation with the following bar:
+
+- State the current behavior, not the implementation history
+- Use concrete commands, file paths, setting keys, and defaults from the diff
+- Remove or rewrite stale text instead of stacking caveats on top of it
+- Keep examples aligned with the current CLI and repository layout
+- Preserve the repository's existing docs tone and heading structure
+
+### 5. Cross-check before finishing
+
+Verify that the updated docs cover the actual delta:
+
+- Search `docs/` for old names, removed flags, or outdated examples
+- Confirm links and relative paths still make sense
+- Confirm any new page is included in the relevant `_meta.ts`
+- Re-read the changed docs against the code diff, not against memory
+
+## Practical heuristics
+
+- If a change affects commands, also check quickstart, workflows, and feature pages for drift.
+- If a change affects configuration, also check `docs/users/configuration/settings.md`, feature pages, and auth/provider docs.
+- If a change affects tools or agent behavior, check both `docs/users/features/**` and `docs/developers/tools/**` when relevant.
+- If tests reveal expected behavior more clearly than implementation code, use tests to confirm wording.
+
+## Deliverable
+
+Produce the docs edits under `docs/` that make the current local changes understandable to a reader who has not seen the diff. Keep the final summary short and identify which pages were updated.

.qwen/skills/docs-update-from-diff/references/docs-surface.md

@@ -0,0 +1,39 @@
+# Docs Surface Map
+
+Use this file to choose the correct destination page under `docs/`.
+
+## Primary sections
+
+- `docs/users/overview.md`, `quickstart.md`, `common-workflow.md`
+  Good for entry points, first-run guidance, and broad user workflows.
+- `docs/users/features/*.md`
+  Good for user-visible features such as skills, MCP, sandbox, sub-agents, commands, checkpointing, and approval modes.
+- `docs/users/configuration/*.md`
+  Good for settings, auth, model providers, themes, trusted folders, `.qwen` files, and similar configuration topics.
+- `docs/users/integration-*.md` and `docs/users/ide-integration/*.md`
+  Good for IDEs, GitHub Actions, and editor companion behavior.
+- `docs/users/extension/*.md`
+  Good for extension authoring and extension usage.
+- `docs/developers/*.md`
+  Good for architecture, contributing workflow, roadmaps, and SDK overviews.
+- `docs/developers/tools/*.md`
+  Good for tool behavior, tool contracts, and implementation-facing explanations.
+- `docs/developers/development/*.md`
+  Good for contributor setup, deployment, tests, telemetry, and automation details.
+
+## Navigation rules
+
+- Root navigation lives in `docs/_meta.ts`.
+- Section navigation lives in the nearest `_meta.ts`, for example:
+  - `docs/users/_meta.ts`
+  - `docs/users/features/_meta.ts`
+  - `docs/developers/_meta.ts`
+  - `docs/developers/tools/_meta.ts`
+- If you create a page and do not add it to the right `_meta.ts`, the docs will be incomplete even if the markdown exists.
+
+## Placement heuristics
+
+- Put the change where a reader would naturally look first.
+- Update multiple pages when a single feature appears in setup, reference, and workflow docs.
+- Prefer adjusting a nearby existing page instead of creating a top-level page for a small delta.
+- Avoid duplicating long explanations across pages; add one source page and update nearby pages with short pointers if needed.

.qwen/skills/terminal-capture/SKILL.md

@@ -109,6 +109,38 @@ Supported key names: `ArrowUp`, `ArrowDown`, `ArrowLeft`, `ArrowRight`, `Enter`,
 
 Auto-screenshot is triggered after the key sequence ends (when the next step is not a `key`).
 
+### `streaming` — Capture During Execution
+
+Capture multiple screenshots at intervals during long-running output (e.g., progress bars). Optionally generates an animated GIF.
+
+```typescript
+{
+  type: 'Run this command: bash progress.sh',
+  streaming: {
+    delayMs: 7000,    // Wait before first capture (skip initial waiting phase)
+    intervalMs: 500,  // Interval between captures
+    count: 20,        // Maximum number of captures
+    gif: true,        // Generate animated GIF (default: true, requires ffmpeg)
+  },
+}
+```
+
+- `delayMs` (optional): Milliseconds to wait after pressing Enter before starting captures. Useful for skipping model thinking/approval time.
+- Captures stop early if terminal output is unchanged for 3 consecutive intervals.
+- Duplicate frames (no output change) are automatically skipped.
+
+**GIF prerequisite**: If the scenario uses `streaming` with GIF enabled (default), check if `ffmpeg` is installed before running. If not, ask the user whether they'd like to install it:
+
+```bash
+# Check
+which ffmpeg
+
+# Install (macOS)
+brew install ffmpeg
+```
+
+If the user declines, the scenario still runs — GIF generation is skipped with a warning.
+
 ### `capture` / `captureFull` — Explicit Screenshot
 
 Use as a standalone step, or override automatic naming:
@@ -178,12 +210,24 @@ This tool is commonly used for visual verification during PR reviews. For the co
 ## Full ScenarioConfig Type
 
 ```typescript
+interface FlowStep {
+  type?: string; // Input text
+  key?: string | string[]; // Key press(es)
+  capture?: string; // Viewport screenshot filename
+  captureFull?: string; // Full scrollback screenshot filename
+  streaming?: {
+    delayMs?: number; // Delay before first capture (default: 0)
+    intervalMs: number; // Interval between captures in ms
+    count: number; // Maximum number of captures
+    gif?: boolean; // Generate animated GIF (default: true)
+  };
+}
+
 interface ScenarioConfig {
   name: string; // Scenario name (also used as screenshot subdirectory name)
   spawn: string[]; // Launch command ["node", "dist/cli.js", "--yolo"]
   flow: FlowStep[]; // Interaction steps
   terminal?: {
-    // Terminal configuration (all optional)
     cols?: number; // Number of columns, default 100
     rows?: number; // Number of rows, default 28
     theme?: string; // Theme: dracula|one-dark|github-dark|monokai|night-owl