Tell Cursor which package actually owns a change in a multi-root monorepo workspace

Why this works

Multi-root workspace support means Cursor's indexer sees several package roots at once and its semantic code search treats that as one searchable space by default — that's the point of the feature for cross-package navigation, but it also means a similarly named file or function in another root is a plausible edit target unless the agent is explicitly told which root actually owns this specific change. Without OWNING_PACKAGE stated up front, a "closest semantic match" search across roots can surface a same-named helper in a sibling package as the thing to modify, or the model can duplicate a type that already exists in a package it was never told to treat as read-only, producing two divergent copies of the same concept that will silently drift apart the moment one gets updated and the other doesn't. Naming shared-file boundaries closes a second, more damaging gap: monorepo root config — workspace manifests, base tsconfig, a shared package's public export list — affects every package silently and simultaneously, so an edit there is exactly the kind of change that should never happen without an explicit ask, even though nothing in a narrowly scoped task description would obviously exclude it from an agent reasoning purely from "what files need to change to make this work." Requiring package-scoped commands over workspace-wide ones prevents a slower but real failure mode where a workspace-level test run silently exercises and reports on packages the change never touched, producing a results summary that looks like broader verification happened when it actually just added noise and runtime without adding signal. The explicit stop-and-confirm rule for ambiguous same-named symbols matters because that ambiguity is invisible from inside a single search result — the agent sees one plausible match per package and has no built-in reason to suspect there's a second one worth checking unless told the possibility exists.