mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-05-02 13:40:46 +00:00
Four findings from /review on the activation extractor:
C1 (Critical): LSP allowlisted but the extractor pushed `filePath`
through unchanged. The LSP tool accepts non-file URI schemes
(`http://`, `git://`, etc.); forwarding any of those to
SkillActivationRegistry as a project-relative candidate let an
LSP call against a non-file resource activate path-gated skills
without the model touching a real project file. Fix is two-part:
decode `file://` URIs via `fileURLToPath` (so a project file
expressed as a URI still activates correctly) and silently drop
any string containing `://` that's not `file://`.
S1: LSP `incomingCalls` / `outgoingCalls` operate on
`callHierarchyItem.uri`, not the top-level `filePath`. After
`prepareCallHierarchy` returns a file-backed item, following the
hierarchy with that item produced no candidate, so path-gated
skills for that file stayed dormant. Same URI-aware extraction is
applied to the nested `uri` field.
S2: grep_search has a path-shaped `glob` field
(`GrepToolParams.glob`) — distinct from `pattern`, which is a
regex on contents. The extractor previously ignored `glob`, so
`grep_search({ pattern, glob: 'src/**/*.ts' })` produced no
activation candidate even though the call walked every file under
`src/**/*.ts`. Same `path + glob` join treatment as GLOB.
S3: No scheduler-side integration test covered the
extractToolFilePaths → matchAndActivateByPaths → reminder-append
wiring, so a regression there could land while extractor and
registry unit tests still passed. Added three integration tests
covering: (a) reminder appended when SkillTool present,
(b) reminder suppressed when SkillTool absent (subagent case),
(c) hook not invoked for non-FS tools.
Restructured `extractToolFilePaths` from a generic
`file_path/filePath/path/paths` extractor into a per-tool
dispatcher (`switch` on canonical tool name). The previous generic
shape was overly permissive — every FS tool got every field name,
including ones it doesn't accept — and it was the wrong shape to
add LSP URI semantics to. Per-tool means each branch reflects the
actual `XToolParams` interface.
Test reshape:
- Removed tests asserting cross-tool field acceptance (e.g. grep
reading `filePath` / `paths`); those documented inaccurate input.
- Added per-tool realistic tests for grep glob, lsp file:// URI,
lsp callHierarchyItem.uri, lsp non-file scheme dropped.
- Plus the three CoreToolScheduler activation wiring tests.
639 tests pass (was 632); types and lint clean.
DEFERRED
S4: Activation driven from input selector rather than concrete
matched files. For `glob({ pattern: '**/*.ts' })` the selector
itself may not match a skill scoped narrower than the query.
Real concern, but the fix needs typed result-path metadata
feedback from each tool — a cross-cutting addition to every FS
tool's return shape. Logged for follow-up.
|
||
|---|---|---|
| .. | ||
| channels | ||
| cli | ||
| core | ||
| sdk-java | ||
| sdk-python | ||
| sdk-typescript | ||
| vscode-ide-companion | ||
| web-templates | ||
| webui | ||
| zed-extension | ||