Workstream OMP extension showed 'This repo is in a workstream-managed directory but is not tracked by any workstream' for a repo that was actually claimed by 5 active workstreams. Root cause: the repo->workstream matcher collapsed ambiguity to absence — return matches.length === 1 ? matches[0] : "" — so the caller could not distinguish 0 matches from N matches, and N>1 fell through to the 'untracked' message, which even suggested creating yet another workstream. General pattern: a resolver that returns a sentinel empty value for both 'none' and 'many' makes over-tracking indistinguishable from untracked.
Return the full match list instead of collapsing, then resolve with a tiered ladder: (1) unique repo match -> use it; (2) multiple matches -> tiebreak on the current git branch (git rev-parse --abbrev-ref HEAD, treating detached HEAD as no branch) against per-workstream branch associations already maintained by the sweep process — a unique branch match resolves unambiguously and the injected message states the chosen workstream plainly, listing the others on one line; (3) still ambiguous -> inject a message listing ALL candidate workstreams with ids, last-code-activity dates, and known branches, instructing the consuming agent to pick based on the session's actual work (the LLM reading the injection has the user's prompt and disambiguates better than any static rule); (4) zero matches -> the 'untracked' message, now truthful. Key insights: (a) never encode 'ambiguous' as 'absent'; (b) when the consumer of a context injection is an LLM, listing candidates with metadata is a valid resolution strategy — don't guess with weak heuristics like recency; (c) branch-name associations recorded by background activity scanners are a free, strong disambiguation signal for repos shared by multiple projects.