[Bug] trigger-policy uses bare focus-dir names as scan roots, so navigation can scan nothing

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.

Start in trigger-policy.ts, focusing on taskMentionedFocusDirs, mergeFocusDirs, and the navigate scan path handling. Reproduce the deep-create-checkout-hook example and inspect how invalid roots and plan-derived directories are processed. Done means prose-matched bare names no longer cause valid targets to be skipped, and non-resolving roots are surfaced or excluded according to the chosen direction.