{"owner":"QwenLM","repo":"qwen-code","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance to Qwen Code when working with code in this\nrepository.\n\n## Working Principles\n\n### Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n**(This is the principle we care about most.)**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes,\nsimplify.\n\n_Adapted from Andrej Karpathy's [CLAUDE.md](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md)._\n\n### Core Infrastructure Is Maintainer-Only (triage gate, two-tier rule)\n\nCore modules — `packages/core/src/**`, `packages/*/src/auth/**`,\n`packages/*/src/providers/**`, `packages/*/src/models/**`,\n`packages/*/src/config/**`, `packages/*/src/tools/**`,\n`packages/*/src/services/**`, cross-package changes — are the architectural\nbackbone. External PRs touching them face a two-tier gate (maintainer-authored\nPRs are exempt):\n\n1. **Large-scope `refactor` changes (500+ production logic lines in core,\n   excluding test and generated/schema files) → hard block.**\n   Skip evaluation entirely — the maintainer exemption above is the sole\n   exception. Large-scale core refactors must be maintainer-initiated.\n   When counting lines, exclude files matching `*.test.ts`, `*.test.tsx`,\n   `*.spec.ts`, `*.spec.tsx`, `__tests__/**`, `*.schema.ts`, `*.schema.json`,\n   `*.generated.ts`, and `**/generated/**` — only production logic counts.\n   `feat`-type and other non-`refactor` PRs are NOT hard-blocked on size; they\n   escalate to the maintainer for awareness instead. A non-blocking advisory\n   also applies at 1000+ production logic lines. Breadth alone is not size — a\n   low-risk sweep that touches 10+\n   files but changes a line or two each is escalated to a maintainer for\n   awareness and otherwise judged under Tier 2's 100%-confidence bar, not\n   auto-rejected on file count.\n2. **Small-scope changes → gate may evaluate, but must be 100% confident.**\n   Any doubt at all → escalate to maintainer. \"The direction looks correct\"\n   is not confidence. The gate must name every downstream consumer; if it\n   cannot, escalate.\n\n**When in doubt, escalate. Better to wrongly escalate than to wrongly\napprove.**\n\n## Common Commands\n\n### Building\n\n```bash\nnpm install        # Install all dependencies\nnpm run build      # Build all packages (TypeScript compilation + asset copying)\nnpm run build:all  # Build everything including sandbox container\nnpm run bundle     # Bundle dist/ into a single dist/cli.js via esbuild\n                   # (requires build first)\n```\n\n`npm run build` compiles TS into each package's `dist/`. `npm run bundle`\ntakes that output and produces a single `dist/cli.js` via esbuild. Bundle\nrequires build to have run first.\n\n### Development\n\n```bash\nnpm run dev        # Run CLI directly from TypeScript source (no build needed)\n```\n\nRuns the CLI via `tsx` with `DEV=true`. Changes to `packages/core` or\n`packages/cli` are reflected immediately without rebuilding.\n\n### Unit Testing\n\nTests must be run from within the specific package directory, not the project\nroot.\n\n**Run individual test files** (always preferred):\n\n```bash\ncd packages/core && npx vitest run src/path/to/file.test.ts\ncd packages/cli && npx vitest run src/path/to/file.test.ts\n```\n\n**Update snapshots:**\n\n```bash\ncd packages/cli && npx vitest run src/path/to/file.test.ts --update\n```\n\n**Avoid:**\n\n- `npm run test -- --filter=...` — does NOT filter; runs the entire suite\n- `npx vitest` from the project root — fails due to package-specific vitest\n  configs\n- Running the whole test suite unless necessary (e.g., final PR verification)\n\n**Test gotchas:**\n\n- In CLI tests, use `vi.hoisted()` for mocks consumed by `vi.mock()` — the\n  mock factory runs at module load time, before test execution.\n\n### Integration Testing\n\nBuild the bundle first: `npm run build && npm run bundle`\n\nRun from the project root using the dedicated npm scripts:\n\n```bash\nnpm run test:integration:cli:sandbox:none\nnpm run test:integration:interactive:sandbox:none\n```\n\nOr combined in one command:\n\n```bash\ncd integration-tests && \\\n  cross-env QWEN_SANDBOX=false npx vitest run cli interactive\n```\n\n**Gotcha:** In interactive tests, always call `session.idle()` between sends —\nANSI output streams asynchronously.\n\n### Linting & Formatting\n\n```bash\nnpm run lint       # ESLint check\nnpm run lint:fix   # Auto-fix lint issues\nnpm run format     # Prettier formatting\nnpm run typecheck  # TypeScript type checking\nnpm run preflight  # Full check: clean → install → format → lint → build\n                   # → typecheck → test\n```\n\n## Code Conventions\n\n- **Module system**: ESM throughout (`\"type\": \"module\"` in all packages)\n- **TypeScript**: Strict mode with `noImplicitAny`, `strictNullChecks`,\n  `noUnusedLocals`, `verbatimModuleSyntax`\n- **Formatting**: Prettier — single quotes, semicolons, trailing commas,\n  2-space indent, 80-char width\n- **Linting**: No `any` types, consistent type imports, no relative imports\n  between packages\n- **Tests**: Collocated with source (`file.test.ts` next to `file.ts`),\n  vitest framework\n- **File naming**: `PascalCase.tsx` for React components, `kebab-case.ts` for\n  `.ts` files in `packages/core` and `packages/cli` (enforced by ESLint). Existing camelCase files are allowlisted in `eslint.legacy-filenames.mjs`; rename opportunistically when touching them, updating all imports in the same commit (note: renames lose `git blame` history).\n- **Comments**: Default to none. Add only when _why_ is non-obvious; don't delete existing ones as cleanup.\n- **Commits**: Conventional Commits (e.g., `feat(cli): Add --json flag`)\n- **Node.js**: Development and production both require `>=22` (Ink 7 + React 19.2 requirement)\n\n### Web Shell UI development\n\n- Prefer the shared primitives in\n  `packages/web-shell/client/components/ui` when developing Web Shell UI. Do\n  not duplicate an existing primitive or rewrite stable CSS Modules solely for\n  consistency.\n- If a required primitive is missing, run\n  `npx shadcn@latest add <component>` from `packages/web-shell`, then review the\n  generated diff. Do not let the CLI overwrite the existing global CSS,\n  semantic tokens, CSS scoping, or portal-root integration. Keep generated\n  components internal unless a public package API is explicitly required.\n- Web Shell supports React 18 and React 19. Generated shadcn components often\n  assume React 19 ref semantics, so wrappers that accept or receive refs —\n  including Radix `asChild`, `Slot`, `Presence`, and portal children — must use\n  `React.forwardRef` and pass the ref to the underlying DOM or Radix primitive.\n  Add a regression test for any ref-sensitive component path.\n- Use unprefixed Tailwind classes and shadcn semantic color tokens such as\n  `background`, `primary`, and `muted`. The package build scopes generated CSS\n  to the Web Shell root and portal root and prefixes global animations and CSS\n  property registrations; changes must preserve that isolation from host-page\n  styles.\n- Components with portals, such as dialogs, popovers, dropdown menus, and\n  tooltips, must use `useWebShellPortalRoot()` as the Radix portal container so\n  themes, scoped CSS, and z-index variables continue to apply. Preserve\n  existing `data-web-shell-*` attributes and public `--web-shell-*` CSS\n  variables. See `packages/web-shell/README.md` for the full conventions.\n\n## Development Guidelines\n\n### General workflow\n\n1. **Design doc for non-trivial work** — write one in `docs/design/` if the\n   change touches multiple files or involves design decisions. Skip for small\n   bugfixes.\n2. **Test plan for behavioral changes** — write an E2E test plan in\n   `.qwen/e2e-tests/` when the change affects user-observable behavior. Dry-run\n   against the global `qwen` CLI first to confirm the baseline.\n3. **Build, typecheck, and test before declaring done**:\n   `npm run build && npm run typecheck`, plus unit tests for the files you\n   changed.\n4. **Self-audit before declaring done** — read the full diff you are about\n   to ship, including new untracked files, in open-ended passes, not hunting\n   for anything specific. Then verify each change, and each green test you\n   rely on as evidence, presuming it wrong (a passing test can assert the\n   wrong thing). Stop after two consecutive clean passes — a clean pass is\n   evidence about that pass, not the code. A fix re-runs step 3, resets the\n   clean-pass count, and gets a further pass over the updated diff — never\n   exit on a pass that found something. If five passes bring no convergence,\n   say so instead of declaring done. Scale to the diff: one clean, careful\n   pass suffices for a trivial change.\n\n### Feature development\n\nUse the `/feat-dev` skill for the full workflow: investigate, design, test plan,\ndry-run, implement, verify, self-audit, code review, and iterate.\n\n### Bugfix\n\nUse the `/bugfix` skill for the reproduce-first workflow: reproduce, fix,\nverify, test, self-audit, and code review.\n\n## Code Review\n\nProject-specific rules for `/review`. The skill loads this section verbatim (by\nits `## Code Review` heading) and hands it to every review agent, so keep it to\nthings a reviewer of _this_ codebase must check — not general advice.\n\n- **Verify a finding against the exact reviewed commit before reporting it.**\n  Read the lines you are about to cite. A Critical that quotes code not present at\n  the commit under review is worse than no finding — it blocks the author over\n  nothing. Do not report a defect you have only inferred from a symbol name or a\n  diff fragment.\n- **A `C=0` / APPROVE is a claim, not a default.** Before submitting one, take\n  each unresolved Critical already on the PR and check it against the code as it\n  stands: _still stands_ / _fixed by this diff_ / _cannot tell_. A GitHub thread\n  can read `isResolved: false, isOutdated: false` for a bug that a later commit\n  fixed on an adjacent line — the flag tracks the anchored line, not the fix.\n- **For every added field, option, or optional parameter, grep its read sites**,\n  including outside the diff. A `foo?: boolean` that is declared and read but never\n  set by any caller is a dead switch (`options.foo ?? true` always takes the\n  default). Decide severity at the read site; never explain an unpopulated field\n  with author intent you cannot observe.\n- **Classify every added or changed daemon route by ownership.** Name whether it\n  is process-global, legacy-primary, selected-runtime, live-session-owner, or\n  persisted-workspace scoped, and verify every downstream consumer matches that\n  scope.\n- **Verify workspace-scoped routes stay inside the resolved runtime.** Check the\n  environment, bridge, service, filesystem, trust boundary, and failure paths.\n  Each unknown, untrusted, ambiguous, bootstrapping, draining, or removed state\n  must follow its declared failure semantics and must never fall back to the\n  primary runtime.\n- **Match the house style when judging.** ESM only; no `any`; no relative imports\n  between packages; `kebab-case.ts` for `.ts` in `packages/core` and `packages/cli`,\n  `PascalCase.tsx` for React components; tests collocated as `file.test.ts`.\n  Comments default to none — flag a _missing_ comment only where the _why_ is\n  genuinely non-obvious, and never fault a diff for deleting a comment that no\n  longer applies.\n- **A missing test for changed behavior is a Suggestion, not a Critical**, unless\n  the untested path is itself the defect.\n\n## GitHub Operations\n\nUse the `gh` CLI for all GitHub-related operations — issues, pull requests,\ncomments, CI checks, releases, and API calls. Prefer `gh issue view`,\n`gh pr view`, `gh pr checks`, `gh run view`, `gh api`, etc. over web fetches\nor manual REST calls.\n\n## Testing, Debugging, and Bug Fixes\n\n- **Bug reproduction & verification**: spawn the `test-engineer` agent. It\n  reads code and docs to understand the bug, then reproduces it via E2E testing\n  (or a test-script fallback). It also handles post-fix verification. It cannot\n  edit source code — only observe and report.\n- **Hard bugs**: use the `structured-debugging` skill when debugging requires\n  more than a quick glance — especially when the first attempt at a fix didn't\n  work or the behavior seems impossible.\n- **E2E testing**: the `e2e-testing` skill covers headless mode, interactive\n  (tmux) mode, MCP server testing, and API traffic inspection. The\n  `test-engineer` agent invokes this skill internally — you typically don't\n  need to use it directly.\n\n## Submitting PRs\n\nWhen creating a PR, follow the template at `.github/pull_request_template.md`.\nAfter the PR is submitted, post a separate comment with the E2E test report if\napplicable.\n\n- **PR description**: explain the motivation and changes in prose. Avoid\n  referencing file names or function names.\n- **Reviewer Test Plan** (template section): describe behaviors a reviewer\n  should verify and what to expect, not scripted test commands. Use **How to\n  verify** for reproduction steps; Before/After for TUI evidence when\n  applicable.\n- **Line wrapping**: do not hard-wrap the PR body at a fixed column width.\n  GitHub renders single newlines as `<br>`, so a wrapped description displays\n  as a narrow column. Write each paragraph or list item as one long line.\n- **Don't let review rounds balloon the PR.** Every accepted change widens the\n  diff and tends to trigger another round, so a PR can drift far past its\n  original intent. Once a PR has been through roughly **5 review rounds**, land\n  only Critical fixes — correctness, security, data loss, regressions — and\n  defer remaining Suggestions to a follow-up issue or PR. Record each deferral\n  in the PR thread so nothing is silently dropped.\n\n## Project Directories\n\nDesign docs and implementation plans are committed under `docs/` so they are\ntracked in version control:\n\n| Directory      | Purpose                          |\n| -------------- | -------------------------------- |\n| `docs/design/` | Design docs for planned features |\n| `docs/plans/`  | Implementation plans             |\n\nOther working artifacts live under `.qwen/` (git-ignored):\n\n| Directory               | Purpose                              |\n| ----------------------- | ------------------------------------ |\n| `.qwen/e2e-tests/`      | E2E test plans and results           |\n| `.qwen/issues/`         | Issue drafts before filing on GitHub |\n| `.qwen/pr-drafts/`      | PR drafts before submitting          |\n| `.qwen/pr-reviews/`     | PR review notes                      |\n| `.qwen/investigations/` | Structured debugging journals        |\n| `.qwen/scripts/`        | Utility scripts                      |\n","CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n**Read [`AGENTS.md`](AGENTS.md) — it is the single source of truth for all coding conventions, build/test commands, code style, commit conventions, PR workflow, and review guidelines. All rules in AGENTS.md apply to Claude Code.**\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance to Qwen Code when working with code in this\nrepository.\n\n## Working Principles\n\n### Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n**(This is the principle we care about most.)**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes,\nsimplify.\n\n_Adapted from Andrej Karpathy's [CLAUDE.md](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md)._\n\n### Core Infrastructure Is Maintainer-Only (triage gate, two-tier rule)\n\nCore modules — `packages/core/src/**`, `packages/*/src/auth/**`,\n`packages/*/src/providers/**`, `packages/*/src/models/**`,\n`packages/*/src/config/**`, `packages/*/src/tools/**`,\n`packages/*/src/services/**`, cross-package changes — are the architectural\nbackbone. External PRs touching them face a two-tier gate (maintainer-authored\nPRs are exempt):\n\n1. **Large-scope `refactor` changes (500+ production logic lines in core,\n   excluding test and generated/schema files) → hard block.**\n   Skip evaluation entirely — the maintainer exemption above is the sole\n   exception. Large-scale core refactors must be maintainer-initiated.\n   When counting lines, exclude files matching `*.test.ts`, `*.test.tsx`,\n   `*.spec.ts`, `*.spec.tsx`, `__tests__/**`, `*.schema.ts`, `*.schema.json`,\n   `*.generated.ts`, and `**/generated/**` — only production logic counts.\n   `feat`-type and other non-`refactor` PRs are NOT hard-blocked on size; they\n   escalate to the maintainer for awareness instead. A non-blocking advisory\n   also applies at 1000+ production logic lines. Breadth alone is not size — a\n   low-risk sweep that touches 10+\n   files but changes a line or two each is escalated to a maintainer for\n   awareness and otherwise judged under Tier 2's 100%-confidence bar, not\n   auto-rejected on file count.\n2. **Small-scope changes → gate may evaluate, but must be 100% confident.**\n   Any doubt at all → escalate to maintainer. \"The direction looks correct\"\n   is not confidence. The gate must name every downstream consumer; if it\n   cannot, escalate.\n\n**When in doubt, escalate. Better to wrongly escalate than to wrongly\napprove.**\n\n## Common Commands\n\n### Building\n\n```bash\nnpm install        # Install all dependencies\nnpm run build      # Build all packages (TypeScript compilation + asset copying)\nnpm run build:all  # Build everything including sandbox container\nnpm run bundle     # Bundle dist/ into a single dist/cli.js via esbuild\n                   # (requires build first)\n```\n\n`npm run build` compiles TS into each package's `dist/`. `npm run bundle`\ntakes that output and produces a single `dist/cli.js` via esbuild. Bundle\nrequires build to have run first.\n\n### Development\n\n```bash\nnpm run dev        # Run CLI directly from TypeScript source (no build needed)\n```\n\nRuns the CLI via `tsx` with `DEV=true`. Changes to `packages/core` or\n`packages/cli` are reflected immediately without rebuilding.\n\n### Unit Testing\n\nTests must be run from within the specific package directory, not the project\nroot.\n\n**Run individual test files** (always preferred):\n\n```bash\ncd packages/core && npx vitest run src/path/to/file.test.ts\ncd packages/cli && npx vitest run src/path/to/file.test.ts\n```\n\n**Update snapshots:**\n\n```bash\ncd packages/cli && npx vitest run src/path/to/file.test.ts --update\n```\n\n**Avoid:**\n\n- `npm run test -- --filter=...` — does NOT filter; runs the entire suite\n- `npx vitest` from the project root — fails due to package-specific vitest\n  configs\n- Running the whole test suite unless necessary (e.g., final PR verification)\n\n**Test gotchas:**\n\n- In CLI tests, use `vi.hoisted()` for mocks consumed by `vi.mock()` — the\n  mock factory runs at module load time, before test execution.\n\n### Integration Testing\n\nBuild the bundle first: `npm run build && npm run bundle`\n\nRun from the project root using the dedicated npm scripts:\n\n```bash\nnpm run test:integration:cli:sandbox:none\nnpm run test:integration:interactive:sandbox:none\n```\n\nOr combined in one command:\n\n```bash\ncd integration-tests && \\\n  cross-env QWEN_SANDBOX=false npx vitest run cli interactive\n```\n\n**Gotcha:** In interactive tests, always call `session.idle()` between sends —\nANSI output streams asynchronously.\n\n### Linting & Formatting\n\n```bash\nnpm run lint       # ESLint check\nnpm run lint:fix   # Auto-fix lint issues\nnpm run format     # Prettier formatting\nnpm run typecheck  # TypeScript type checking\nnpm run preflight  # Full check: clean → install → format → lint → build\n                   # → typecheck → test\n```\n\n## Code Conventions\n\n- **Module system**: ESM throughout (`\"type\": \"module\"` in all packages)\n- **TypeScript**: Strict mode with `noImplicitAny`, `strictNullChecks`,\n  `noUnusedLocals`, `verbatimModuleSyntax`\n- **Formatting**: Prettier — single quotes, semicolons, trailing commas,\n  2-space indent, 80-char width\n- **Linting**: No `any` types, consistent type imports, no relative imports\n  between packages\n- **Tests**: Collocated with source (`file.test.ts` next to `file.ts`),\n  vitest framework\n- **File naming**: `PascalCase.tsx` for React components, `kebab-case.ts` for\n  `.ts` files in `packages/core` and `packages/cli` (enforced by ESLint). Existing camelCase files are allowlisted in `eslint.legacy-filenames.mjs`; rename opportunistically when touching them, updating all imports in the same commit (note: renames lose `git blame` history).\n- **Comments**: Default to none. Add only when _why_ is non-obvious; don't delete existing ones as cleanup.\n- **Commits**: Conventional Commits (e.g., `feat(cli): Add --json flag`)\n- **Node.js**: Development and production both require `>=22` (Ink 7 + React 19.2 requirement)\n\n### Web Shell UI development\n\n- Prefer the shared primitives in\n  `packages/web-shell/client/components/ui` when developing Web Shell UI. Do\n  not duplicate an existing primitive or rewrite stable CSS Modules solely for\n  consistency.\n- If a required primitive is missing, run\n  `npx shadcn@latest add <component>` from `packages/web-shell`, then review the\n  generated diff. Do not let the CLI overwrite the existing global CSS,\n  semantic tokens, CSS scoping, or portal-root integration. Keep generated\n  components internal unless a public package API is explicitly required.\n- Web Shell supports React 18 and React 19. Generated shadcn components often\n  assume React 19 ref semantics, so wrappers that accept or receive refs —\n  including Radix `asChild`, `Slot`, `Presence`, and portal children — must use\n  `React.forwardRef` and pass the ref to the underlying DOM or Radix primitive.\n  Add a regression test for any ref-sensitive component path.\n- Use unprefixed Tailwind classes and shadcn semantic color tokens such as\n  `background`, `primary`, and `muted`. The package build scopes generated CSS\n  to the Web Shell root and portal root and prefixes global animations and CSS\n  property registrations; changes must preserve that isolation from host-page\n  styles.\n- Components with portals, such as dialogs, popovers, dropdown menus, and\n  tooltips, must use `useWebShellPortalRoot()` as the Radix portal container so\n  themes, scoped CSS, and z-index variables continue to apply. Preserve\n  existing `data-web-shell-*` attributes and public `--web-shell-*` CSS\n  variables. See `packages/web-shell/README.md` for the full conventions.\n\n## Development Guidelines\n\n### General workflow\n\n1. **Design doc for non-trivial work** — write one in `docs/design/` if the\n   change touches multiple files or involves design decisions. Skip for small\n   bugfixes.\n2. **Test plan for behavioral changes** — write an E2E test plan in\n   `.qwen/e2e-tests/` when the change affects user-observable behavior. Dry-run\n   against the global `qwen` CLI first to confirm the baseline.\n3. **Build, typecheck, and test before declaring done**:\n   `npm run build && npm run typecheck`, plus unit tests for the files you\n   changed.\n4. **Self-audit before declaring done** — read the full diff you are about\n   to ship, including new untracked files, in open-ended passes, not hunting\n   for anything specific. Then verify each change, and each green test you\n   rely on as evidence, presuming it wrong (a passing test can assert the\n   wrong thing). Stop after two consecutive clean passes — a clean pass is\n   evidence about that pass, not the code. A fix re-runs step 3, resets the\n   clean-pass count, and gets a further pass over the updated diff — never\n   exit on a pass that found something. If five passes bring no convergence,\n   say so instead of declaring done. Scale to the diff: one clean, careful\n   pass suffices for a trivial change.\n\n### Feature development\n\nUse the `/feat-dev` skill for the full workflow: investigate, design, test plan,\ndry-run, implement, verify, self-audit, code review, and iterate.\n\n### Bugfix\n\nUse the `/bugfix` skill for the reproduce-first workflow: reproduce, fix,\nverify, test, self-audit, and code review.\n\n## Code Review\n\nProject-specific rules for `/review`. The skill loads this section verbatim (by\nits `## Code Review` heading) and hands it to every review agent, so keep it to\nthings a reviewer of _this_ codebase must check — not general advice.\n\n- **Verify a finding against the exact reviewed commit before reporting it.**\n  Read the lines you are about to cite. A Critical that quotes code not present at\n  the commit under review is worse than no finding — it blocks the author over\n  nothing. Do not report a defect you have only inferred from a symbol name or a\n  diff fragment.\n- **A `C=0` / APPROVE is a claim, not a default.** Before submitting one, take\n  each unresolved Critical already on the PR and check it against the code as it\n  stands: _still stands_ / _fixed by this diff_ / _cannot tell_. A GitHub thread\n  can read `isResolved: false, isOutdated: false` for a bug that a later commit\n  fixed on an adjacent line — the flag tracks the anchored line, not the fix.\n- **For every added field, option, or optional parameter, grep its read sites**,\n  including outside the diff. A `foo?: boolean` that is declared and read but never\n  set by any caller is a dead switch (`options.foo ?? true` always takes the\n  default). Decide severity at the read site; never explain an unpopulated field\n  with author intent you cannot observe.\n- **Classify every added or changed daemon route by ownership.** Name whether it\n  is process-global, legacy-primary, selected-runtime, live-session-owner, or\n  persisted-workspace scoped, and verify every downstream consumer matches that\n  scope.\n- **Verify workspace-scoped routes stay inside the resolved runtime.** Check the\n  environment, bridge, service, filesystem, trust boundary, and failure paths.\n  Each unknown, untrusted, ambiguous, bootstrapping, draining, or removed state\n  must follow its declared failure semantics and must never fall back to the\n  primary runtime.\n- **Match the house style when judging.** ESM only; no `any`; no relative imports\n  between packages; `kebab-case.ts` for `.ts` in `packages/core` and `packages/cli`,\n  `PascalCase.tsx` for React components; tests collocated as `file.test.ts`.\n  Comments default to none — flag a _missing_ comment only where the _why_ is\n  genuinely non-obvious, and never fault a diff for deleting a comment that no\n  longer applies.\n- **A missing test for changed behavior is a Suggestion, not a Critical**, unless\n  the untested path is itself the defect.\n\n## GitHub Operations\n\nUse the `gh` CLI for all GitHub-related operations — issues, pull requests,\ncomments, CI checks, releases, and API calls. Prefer `gh issue view`,\n`gh pr view`, `gh pr checks`, `gh run view`, `gh api`, etc. over web fetches\nor manual REST calls.\n\n## Testing, Debugging, and Bug Fixes\n\n- **Bug reproduction & verification**: spawn the `test-engineer` agent. It\n  reads code and docs to understand the bug, then reproduces it via E2E testing\n  (or a test-script fallback). It also handles post-fix verification. It cannot\n  edit source code — only observe and report.\n- **Hard bugs**: use the `structured-debugging` skill when debugging requires\n  more than a quick glance — especially when the first attempt at a fix didn't\n  work or the behavior seems impossible.\n- **E2E testing**: the `e2e-testing` skill covers headless mode, interactive\n  (tmux) mode, MCP server testing, and API traffic inspection. The\n  `test-engineer` agent invokes this skill internally — you typically don't\n  need to use it directly.\n\n## Submitting PRs\n\nWhen creating a PR, follow the template at `.github/pull_request_template.md`.\nAfter the PR is submitted, post a separate comment with the E2E test report if\napplicable.\n\n- **PR description**: explain the motivation and changes in prose. Avoid\n  referencing file names or function names.\n- **Reviewer Test Plan** (template section): describe behaviors a reviewer\n  should verify and what to expect, not scripted test commands. Use **How to\n  verify** for reproduction steps; Before/After for TUI evidence when\n  applicable.\n- **Line wrapping**: do not hard-wrap the PR body at a fixed column width.\n  GitHub renders single newlines as `<br>`, so a wrapped description displays\n  as a narrow column. Write each paragraph or list item as one long line.\n- **Don't let review rounds balloon the PR.** Every accepted change widens the\n  diff and tends to trigger another round, so a PR can drift far past its\n  original intent. Once a PR has been through roughly **5 review rounds**, land\n  only Critical fixes — correctness, security, data loss, regressions — and\n  defer remaining Suggestions to a follow-up issue or PR. Record each deferral\n  in the PR thread so nothing is silently dropped.\n\n## Project Directories\n\nDesign docs and implementation plans are committed under `docs/` so they are\ntracked in version control:\n\n| Directory      | Purpose                          |\n| -------------- | -------------------------------- |\n| `docs/design/` | Design docs for planned features |\n| `docs/plans/`  | Implementation plans             |\n\nOther working artifacts live under `.qwen/` (git-ignored):\n\n| Directory               | Purpose                              |\n| ----------------------- | ------------------------------------ |\n| `.qwen/e2e-tests/`      | E2E test plans and results           |\n| `.qwen/issues/`         | Issue drafts before filing on GitHub |\n| `.qwen/pr-drafts/`      | PR drafts before submitting          |\n| `.qwen/pr-reviews/`     | PR review notes                      |\n| `.qwen/investigations/` | Structured debugging journals        |\n| `.qwen/scripts/`        | Utility scripts                      |\n","CLAUDE.md":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n**Read [`AGENTS.md`](AGENTS.md) — it is the single source of truth for all coding conventions, build/test commands, code style, commit conventions, PR workflow, and review guidelines. All rules in AGENTS.md apply to Claude Code.**\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# AGENTS.md\n\nThis file provides guidance to Qwen Code when working with code in this\nrepository.\n\n## Working Principles\n\n### Simplicity First\n\n**Minimum code that solves the problem. Nothing speculative.**\n**(This is the principle we care about most.)**\n\n- No features beyond what was asked.\n- No abstractions for single-use code.\n- No \"flexibility\" or \"configurability\" that wasn't requested.\n- No error handling for impossible scenarios.\n- If you write 200 lines and it could be 50, rewrite it.\n\nAsk yourself: \"Would a senior engineer say this is overcomplicated?\" If yes,\nsimplify.\n\n_Adapted from Andrej Karpathy's [CLAUDE.md](https://github.com/multica-ai/andrej-karpathy-skills/blob/main/CLAUDE.md)._\n\n### Core Infrastructure Is Maintainer-Only (triage gate, two-tier rule)\n\nCore modules — `packages/core/src/**`, `packages/*/src/auth/**`,\n`packages/*/src/providers/**`, `packages/*/src/models/**`,\n`packages/*/src/config/**`, `packages/*/src/tools/**`,\n`packages/*/src/services/**`, cross-package changes — are the architectural\nbackbone. External PRs touching them face a two-tier gate (maintainer-authored\nPRs are exempt):\n\n1. **Large-scope `refactor` changes (500+ production logic lines in core,\n   excluding test and generated/schema files) → hard block.**\n   Skip evaluation entirely — the maintainer exemption above is the sole\n   exception. Large-scale core refactors must be maintainer-initiated.\n   When counting lines, exclude files matching `*.test.ts`, `*.test.tsx`,\n   `*.spec.ts`, `*.spec.tsx`, `__tests__/**`, `*.schema.ts`, `*.schema.json`,\n   `*.generated.ts`, and `**/generated/**` — only production logic counts.\n   `feat`-type and other non-`refactor` PRs are NOT hard-blocked on size; they\n   escalate to the maintainer for awareness instead. A non-blocking advisory\n   also applies at 1000+ production logic lines. Breadth alone is not size — a\n   low-risk sweep that touches 10+\n   files but changes a line or two each is escalated to a maintainer for\n   awareness and otherwise judged under Tier 2's 100%-confidence bar, not\n   auto-rejected on file count.\n2. **Small-scope changes → gate may evaluate, but must be 100% confident.**\n   Any doubt at all → escalate to maintainer. \"The direction looks correct\"\n   is not confidence. The gate must name every downstream consumer; if it\n   cannot, escalate.\n\n**When in doubt, escalate. Better to wrongly escalate than to wrongly\napprove.**\n\n## Common Commands\n\n### Building\n\n```bash\nnpm install        # Install all dependencies\nnpm run build      # Build all packages (TypeScript compilation + asset copying)\nnpm run build:all  # Build everything including sandbox container\nnpm run bundle     # Bundle dist/ into a single dist/cli.js via esbuild\n                   # (requires build first)\n```\n\n`npm run build` compiles TS into each package's `dist/`. `npm run bundle`\ntakes that output and produces a single `dist/cli.js` via esbuild. Bundle\nrequires build to have run first.\n\n### Development\n\n```bash\nnpm run dev        # Run CLI directly from TypeScript source (no build needed)\n```\n\nRuns the CLI via `tsx` with `DEV=true`. Changes to `packages/core` or\n`packages/cli` are reflected immediately without rebuilding.\n\n### Unit Testing\n\nTests must be run from within the specific package directory, not the project\nroot.\n\n**Run individual test files** (always preferred):\n\n```bash\ncd packages/core && npx vitest run src/path/to/file.test.ts\ncd packages/cli && npx vitest run src/path/to/file.test.ts\n```\n\n**Update snapshots:**\n\n```bash\ncd packages/cli && npx vitest run src/path/to/file.test.ts --update\n```\n\n**Avoid:**\n\n- `npm run test -- --filter=...` — does NOT filter; runs the entire suite\n- `npx vitest` from the project root — fails due to package-specific vitest\n  configs\n- Running the whole test suite unless necessary (e.g., final PR verification)\n\n**Test gotchas:**\n\n- In CLI tests, use `vi.hoisted()` for mocks consumed by `vi.mock()` — the\n  mock factory runs at module load time, before test execution.\n\n### Integration Testing\n\nBuild the bundle first: `npm run build && npm run bundle`\n\nRun from the project root using the dedicated npm scripts:\n\n```bash\nnpm run test:integration:cli:sandbox:none\nnpm run test:integration:interactive:sandbox:none\n```\n\nOr combined in one command:\n\n```bash\ncd integration-tests && \\\n  cross-env QWEN_SANDBOX=false npx vitest run cli interactive\n```\n\n**Gotcha:** In interactive tests, always call `session.idle()` between sends —\nANSI output streams asynchronously.\n\n### Linting & Formatting\n\n```bash\nnpm run lint       # ESLint check\nnpm run lint:fix   # Auto-fix lint issues\nnpm run format     # Prettier formatting\nnpm run typecheck  # TypeScript type checking\nnpm run preflight  # Full check: clean → install → format → lint → build\n                   # → typecheck → test\n```\n\n## Code Conventions\n\n- **Module system**: ESM throughout (`\"type\": \"module\"` in all packages)\n- **TypeScript**: Strict mode with `noImplicitAny`, `strictNullChecks`,\n  `noUnusedLocals`, `verbatimModuleSyntax`\n- **Formatting**: Prettier — single quotes, semicolons, trailing commas,\n  2-space indent, 80-char width\n- **Linting**: No `any` types, consistent type imports, no relative imports\n  between packages\n- **Tests**: Collocated with source (`file.test.ts` next to `file.ts`),\n  vitest framework\n- **File naming**: `PascalCase.tsx` for React components, `kebab-case.ts` for\n  `.ts` files in `packages/core` and `packages/cli` (enforced by ESLint). Existing camelCase files are allowlisted in `eslint.legacy-filenames.mjs`; rename opportunistically when touching them, updating all imports in the same commit (note: renames lose `git blame` history).\n- **Comments**: Default to none. Add only when _why_ is non-obvious; don't delete existing ones as cleanup.\n- **Commits**: Conventional Commits (e.g., `feat(cli): Add --json flag`)\n- **Node.js**: Development and production both require `>=22` (Ink 7 + React 19.2 requirement)\n\n### Web Shell UI development\n\n- Prefer the shared primitives in\n  `packages/web-shell/client/components/ui` when developing Web Shell UI. Do\n  not duplicate an existing primitive or rewrite stable CSS Modules solely for\n  consistency.\n- If a required primitive is missing, run\n  `npx shadcn@latest add <component>` from `packages/web-shell`, then review the\n  generated diff. Do not let the CLI overwrite the existing global CSS,\n  semantic tokens, CSS scoping, or portal-root integration. Keep generated\n  components internal unless a public package API is explicitly required.\n- Web Shell supports React 18 and React 19. Generated shadcn components often\n  assume React 19 ref semantics, so wrappers that accept or receive refs —\n  including Radix `asChild`, `Slot`, `Presence`, and portal children — must use\n  `React.forwardRef` and pass the ref to the underlying DOM or Radix primitive.\n  Add a regression test for any ref-sensitive component path.\n- Use unprefixed Tailwind classes and shadcn semantic color tokens such as\n  `background`, `primary`, and `muted`. The package build scopes generated CSS\n  to the Web Shell root and portal root and prefixes global animations and CSS\n  property registrations; changes must preserve that isolation from host-page\n  styles.\n- Components with portals, such as dialogs, popovers, dropdown menus, and\n  tooltips, must use `useWebShellPortalRoot()` as the Radix portal container so\n  themes, scoped CSS, and z-index variables continue to apply. Preserve\n  existing `data-web-shell-*` attributes and public `--web-shell-*` CSS\n  variables. See `packages/web-shell/README.md` for the full conventions.\n\n## Development Guidelines\n\n### General workflow\n\n1. **Design doc for non-trivial work** — write one in `docs/design/` if the\n   change touches multiple files or involves design decisions. Skip for small\n   bugfixes.\n2. **Test plan for behavioral changes** — write an E2E test plan in\n   `.qwen/e2e-tests/` when the change affects user-observable behavior. Dry-run\n   against the global `qwen` CLI first to confirm the baseline.\n3. **Build, typecheck, and test before declaring done**:\n   `npm run build && npm run typecheck`, plus unit tests for the files you\n   changed.\n4. **Self-audit before declaring done** — read the full diff you are about\n   to ship, including new untracked files, in open-ended passes, not hunting\n   for anything specific. Then verify each change, and each green test you\n   rely on as evidence, presuming it wrong (a passing test can assert the\n   wrong thing). Stop after two consecutive clean passes — a clean pass is\n   evidence about that pass, not the code. A fix re-runs step 3, resets the\n   clean-pass count, and gets a further pass over the updated diff — never\n   exit on a pass that found something. If five passes bring no convergence,\n   say so instead of declaring done. Scale to the diff: one clean, careful\n   pass suffices for a trivial change.\n\n### Feature development\n\nUse the `/feat-dev` skill for the full workflow: investigate, design, test plan,\ndry-run, implement, verify, self-audit, code review, and iterate.\n\n### Bugfix\n\nUse the `/bugfix` skill for the reproduce-first workflow: reproduce, fix,\nverify, test, self-audit, and code review.\n\n## Code Review\n\nProject-specific rules for `/review`. The skill loads this section verbatim (by\nits `## Code Review` heading) and hands it to every review agent, so keep it to\nthings a reviewer of _this_ codebase must check — not general advice.\n\n- **Verify a finding against the exact reviewed commit before reporting it.**\n  Read the lines you are about to cite. A Critical that quotes code not present at\n  the commit under review is worse than no finding — it blocks the author over\n  nothing. Do not report a defect you have only inferred from a symbol name or a\n  diff fragment.\n- **A `C=0` / APPROVE is a claim, not a default.** Before submitting one, take\n  each unresolved Critical already on the PR and check it against the code as it\n  stands: _still stands_ / _fixed by this diff_ / _cannot tell_. A GitHub thread\n  can read `isResolved: false, isOutdated: false` for a bug that a later commit\n  fixed on an adjacent line — the flag tracks the anchored line, not the fix.\n- **For every added field, option, or optional parameter, grep its read sites**,\n  including outside the diff. A `foo?: boolean` that is declared and read but never\n  set by any caller is a dead switch (`options.foo ?? true` always takes the\n  default). Decide severity at the read site; never explain an unpopulated field\n  with author intent you cannot observe.\n- **Classify every added or changed daemon route by ownership.** Name whether it\n  is process-global, legacy-primary, selected-runtime, live-session-owner, or\n  persisted-workspace scoped, and verify every downstream consumer matches that\n  scope.\n- **Verify workspace-scoped routes stay inside the resolved runtime.** Check the\n  environment, bridge, service, filesystem, trust boundary, and failure paths.\n  Each unknown, untrusted, ambiguous, bootstrapping, draining, or removed state\n  must follow its declared failure semantics and must never fall back to the\n  primary runtime.\n- **Match the house style when judging.** ESM only; no `any`; no relative imports\n  between packages; `kebab-case.ts` for `.ts` in `packages/core` and `packages/cli`,\n  `PascalCase.tsx` for React components; tests collocated as `file.test.ts`.\n  Comments default to none — flag a _missing_ comment only where the _why_ is\n  genuinely non-obvious, and never fault a diff for deleting a comment that no\n  longer applies.\n- **A missing test for changed behavior is a Suggestion, not a Critical**, unless\n  the untested path is itself the defect.\n\n## GitHub Operations\n\nUse the `gh` CLI for all GitHub-related operations — issues, pull requests,\ncomments, CI checks, releases, and API calls. Prefer `gh issue view`,\n`gh pr view`, `gh pr checks`, `gh run view`, `gh api`, etc. over web fetches\nor manual REST calls.\n\n## Testing, Debugging, and Bug Fixes\n\n- **Bug reproduction & verification**: spawn the `test-engineer` agent. It\n  reads code and docs to understand the bug, then reproduces it via E2E testing\n  (or a test-script fallback). It also handles post-fix verification. It cannot\n  edit source code — only observe and report.\n- **Hard bugs**: use the `structured-debugging` skill when debugging requires\n  more than a quick glance — especially when the first attempt at a fix didn't\n  work or the behavior seems impossible.\n- **E2E testing**: the `e2e-testing` skill covers headless mode, interactive\n  (tmux) mode, MCP server testing, and API traffic inspection. The\n  `test-engineer` agent invokes this skill internally — you typically don't\n  need to use it directly.\n\n## Submitting PRs\n\nWhen creating a PR, follow the template at `.github/pull_request_template.md`.\nAfter the PR is submitted, post a separate comment with the E2E test report if\napplicable.\n\n- **PR description**: explain the motivation and changes in prose. Avoid\n  referencing file names or function names.\n- **Reviewer Test Plan** (template section): describe behaviors a reviewer\n  should verify and what to expect, not scripted test commands. Use **How to\n  verify** for reproduction steps; Before/After for TUI evidence when\n  applicable.\n- **Line wrapping**: do not hard-wrap the PR body at a fixed column width.\n  GitHub renders single newlines as `<br>`, so a wrapped description displays\n  as a narrow column. Write each paragraph or list item as one long line.\n- **Don't let review rounds balloon the PR.** Every accepted change widens the\n  diff and tends to trigger another round, so a PR can drift far past its\n  original intent. Once a PR has been through roughly **5 review rounds**, land\n  only Critical fixes — correctness, security, data loss, regressions — and\n  defer remaining Suggestions to a follow-up issue or PR. Record each deferral\n  in the PR thread so nothing is silently dropped.\n\n## Project Directories\n\nDesign docs and implementation plans are committed under `docs/` so they are\ntracked in version control:\n\n| Directory      | Purpose                          |\n| -------------- | -------------------------------- |\n| `docs/design/` | Design docs for planned features |\n| `docs/plans/`  | Implementation plans             |\n\nOther working artifacts live under `.qwen/` (git-ignored):\n\n| Directory               | Purpose                              |\n| ----------------------- | ------------------------------------ |\n| `.qwen/e2e-tests/`      | E2E test plans and results           |\n| `.qwen/issues/`         | Issue drafts before filing on GitHub |\n| `.qwen/pr-drafts/`      | PR drafts before submitting          |\n| `.qwen/pr-reviews/`     | PR review notes                      |\n| `.qwen/investigations/` | Structured debugging journals        |\n| `.qwen/scripts/`        | Utility scripts                      |\n","category":"root","tokens":3711},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"# CLAUDE.md\n\nThis file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.\n\n**Read [`AGENTS.md`](AGENTS.md) — it is the single source of truth for all coding conventions, build/test commands, code style, commit conventions, PR workflow, and review guidelines. All rules in AGENTS.md apply to Claude Code.**\n","category":"root","tokens":87}]}