Found while following the skill on a Jmix 3.0.1 project.
Problem: silent — the skill guards against a false-clean EMPTY result and against "URI is not registered", but has no rule for the opposite failure: an all-errors result from a file the connected IDE does not index.
Task
Editing a Flow UI fragment (a controller plus its XML descriptor) whose files live in a git worktree nested under the project root, while the connected JetBrains IDE is opened on the main checkout.
Where
The Gate-1 step "PRIMARY when connected: run a Jmix-aware IDE/semantic inspection (e.g. JetBrains get_file_problems) on every file you created/edited." It treats a connected IDE as authoritative without checking that the IDE indexes the edited files.
What happened
Running the inspection on the worktree copies reported "Cannot resolve symbol" for practically every symbol, including JDK types such as String, List and Map — the IDE indexes the main checkout as the module and does not index files under the worktree path. Every Java finding was a false positive. The one descriptor finding (an msg:// key reported missing) was false too: the identical key in the identical package resolved with zero errors in the sibling descriptor under the main checkout. Recognizing the results as bogus required stepping outside the skill to run a control inspection on the main checkout; it was later reproduced as a controlled A/B on a single file present in both places — the main-checkout copy returned only genuine Jmix findings, the worktree copy returned dozens of bogus errors, and a descriptor clean in the main checkout returned "message not found" in the worktree for keys present in the worktree's own messages_*.properties. Caught by the IDE inspection itself, once cross-checked.
Three properties make this failure mode dangerous rather than merely noisy. First, the bogus findings carry severity ERROR, so an errors-only filter does not remove them, and the skill treats errors as blockers — an agent that trusts them starts "fixing" healthy code. Second, it silently coexists with the worktree layout agent tooling creates by default (worktrees nested inside the project root, e.g. under a .claude/worktrees/ directory): because the file is inside the project directory, the tool inspects it and returns garbage instead of refusing loudly the way it does for a path outside the project. Third, the same signature arises from any unindexed path, not only worktrees — a file outside a source root, a Gradle project never (re)imported, or indexing lag after files were written from outside the IDE.
Suggested fix
Add a second entry to the "Fallback decision rule": an IDE inspection is authoritative only for files the connected IDE actually indexes. Name the failure signature — practically every symbol unresolved, including JDK types like String, List and Map — as "the IDE is not indexing this file"; on that signature, disregard the whole result (in particular, do not fix code from it) and fall back to compileJava plus the mechanical descriptor checks. For XML-only edits, where no JDK-type signature exists, the analogue is "message not found" for msg:// keys that grep resolves in the module's messages_*.properties. A mechanical precondition that works for any file type: compare git rev-parse --show-toplevel for the edited file against projectPath — if they differ, the file lives in another worktree and the inspection of that path is not authoritative. Call out git worktrees as the most common cause: agent tooling routinely creates worktrees nested under the project root, and when the IDE is opened on the main checkout those files are typically not indexed.
Found while following the skill on a Jmix 3.0.1 project.
Problem: silent — the skill guards against a false-clean EMPTY result and against "URI is not registered", but has no rule for the opposite failure: an all-errors result from a file the connected IDE does not index.
Task
Editing a Flow UI fragment (a controller plus its XML descriptor) whose files live in a git worktree nested under the project root, while the connected JetBrains IDE is opened on the main checkout.
Where
The Gate-1 step "PRIMARY when connected: run a Jmix-aware IDE/semantic inspection (e.g. JetBrains get_file_problems) on every file you created/edited." It treats a connected IDE as authoritative without checking that the IDE indexes the edited files.
What happened
Running the inspection on the worktree copies reported "Cannot resolve symbol" for practically every symbol, including JDK types such as String, List and Map — the IDE indexes the main checkout as the module and does not index files under the worktree path. Every Java finding was a false positive. The one descriptor finding (an msg:// key reported missing) was false too: the identical key in the identical package resolved with zero errors in the sibling descriptor under the main checkout. Recognizing the results as bogus required stepping outside the skill to run a control inspection on the main checkout; it was later reproduced as a controlled A/B on a single file present in both places — the main-checkout copy returned only genuine Jmix findings, the worktree copy returned dozens of bogus errors, and a descriptor clean in the main checkout returned "message not found" in the worktree for keys present in the worktree's own messages_*.properties. Caught by the IDE inspection itself, once cross-checked.
Three properties make this failure mode dangerous rather than merely noisy. First, the bogus findings carry severity ERROR, so an errors-only filter does not remove them, and the skill treats errors as blockers — an agent that trusts them starts "fixing" healthy code. Second, it silently coexists with the worktree layout agent tooling creates by default (worktrees nested inside the project root, e.g. under a
.claude/worktrees/directory): because the file is inside the project directory, the tool inspects it and returns garbage instead of refusing loudly the way it does for a path outside the project. Third, the same signature arises from any unindexed path, not only worktrees — a file outside a source root, a Gradle project never (re)imported, or indexing lag after files were written from outside the IDE.Suggested fix
Add a second entry to the "Fallback decision rule": an IDE inspection is authoritative only for files the connected IDE actually indexes. Name the failure signature — practically every symbol unresolved, including JDK types like String, List and Map — as "the IDE is not indexing this file"; on that signature, disregard the whole result (in particular, do not fix code from it) and fall back to compileJava plus the mechanical descriptor checks. For XML-only edits, where no JDK-type signature exists, the analogue is "message not found" for msg:// keys that grep resolves in the module's messages_*.properties. A mechanical precondition that works for any file type: compare
git rev-parse --show-toplevelfor the edited file againstprojectPath— if they differ, the file lives in another worktree and the inspection of that path is not authoritative. Call out git worktrees as the most common cause: agent tooling routinely creates worktrees nested under the project root, and when the IDE is opened on the main checkout those files are typically not indexed.