What
trigger-policy.ts builds the navigate step's paths by merging directory names matched out of the task description text with directories collected from the plan's steps:
// trigger-policy.ts
const FOCUS_DIRS = ['src', 'components', 'hooks', 'api', 'services', 'pages', ...];
function taskMentionedFocusDirs(task: AgentTask): string[] {
const text = task.description.toLowerCase();
return FOCUS_DIRS.filter((dir) => new RegExp(`(^|[^a-z0-9_-])${dir}([^a-z0-9_-]|$)`).test(text));
}
function mergeFocusDirs(task, dirs, limit = 5) {
return uniqueDirs([...taskMentionedFocusDirs(task), ...dirs], limit);
}The matched names are bare — hooks, components, api — and are used directly as scan roots. They are not resolved against the repository, so unless such a directory happens to exist at the root, the scan root does not exist.
They are also placed first, ahead of the real target directories derived from the plan's steps, and uniqueDirs caps the list at 5.
Observed
deep-create-checkout-hook — "give the checkout feature a useCheckoutTotal hook, in that feature's own hooks directory":
{ "intent": "prepare_create",
"paths": ["hooks", "src/features/checkout", "src/features/checkout/hooks"],
"entries": 0, "candidateCount": 0 }hooks matched the task text and became the first scan root. The repository has no root-level hooks/. The scan returned 0 entries and 0 candidates despite two of the three paths being valid, feature-sliced targets.
An earlier run of the same task showed paths: ["hooks", "src"], also 0 entries.
Why it matters
The task still passed — localization came from elsewhere — but the navigation contributed nothing, which is precisely the outcome a filesense ablation is meant to detect and attribute. A capability that silently scans nothing looks identical to a capability that is not helping.
The failure is silent: a non-existent scan root yields no warning, just an empty result. warnings: [].
Suggested direction
Either resolve focus-dir names against the repository before using them as roots (hooks → the hooks directories that actually exist, or drop it), or keep them only as ranking hints for candidates found under real roots rather than as roots themselves. Their current position — first in the list, ahead of the paths derived from the actual plan — is also worth revisiting; a name lifted from prose is weaker evidence than a directory the plan is about to write into.
A non-resolving scan root should at minimum produce a warning rather than an empty result.
Related
Found while running the filesense ablation (#412). Same family as #415 / #417 / #419: the capability works, and its output is discarded or misdirected downstream.
What
trigger-policy.tsbuilds the navigate step'spathsby merging directory names matched out of the task description text with directories collected from the plan's steps:The matched names are bare —
hooks,components,api— and are used directly as scan roots. They are not resolved against the repository, so unless such a directory happens to exist at the root, the scan root does not exist.They are also placed first, ahead of the real target directories derived from the plan's steps, and
uniqueDirscaps the list at 5.Observed
deep-create-checkout-hook— "give the checkout feature auseCheckoutTotalhook, in that feature's own hooks directory":{ "intent": "prepare_create", "paths": ["hooks", "src/features/checkout", "src/features/checkout/hooks"], "entries": 0, "candidateCount": 0 }hooksmatched the task text and became the first scan root. The repository has no root-levelhooks/. The scan returned 0 entries and 0 candidates despite two of the three paths being valid, feature-sliced targets.An earlier run of the same task showed
paths: ["hooks", "src"], also 0 entries.Why it matters
The task still passed — localization came from elsewhere — but the navigation contributed nothing, which is precisely the outcome a filesense ablation is meant to detect and attribute. A capability that silently scans nothing looks identical to a capability that is not helping.
The failure is silent: a non-existent scan root yields no warning, just an empty result.
warnings: [].Suggested direction
Either resolve focus-dir names against the repository before using them as roots (
hooks→ thehooksdirectories that actually exist, or drop it), or keep them only as ranking hints for candidates found under real roots rather than as roots themselves. Their current position — first in the list, ahead of the paths derived from the actual plan — is also worth revisiting; a name lifted from prose is weaker evidence than a directory the plan is about to write into.A non-resolving scan root should at minimum produce a
warningrather than an empty result.Related
Found while running the filesense ablation (#412). Same family as #415 / #417 / #419: the capability works, and its output is discarded or misdirected downstream.