Merge remote main into fix/pdf-session-corruption

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

.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