fix(resolve): use an org slug only when no project matches

[betegon]

Summary

A bare target was resolved differently depending on the command and cache state. sentry issue list acme and sentry explore acme could fail when acme was an organization, while a warm cache could make the organization win even when a project had the same slug.

Target resolution now has one shared order:

1. exact project match(es)
2. exact organization match
3. fuzzy project recovery
4. not found

The slash forms stay explicit: <org>/ selects the organization and <org>/<project> selects that project. Without a slash, a project always wins when a project and organization share the same slug. Commands that support organization scope fall back to the organization only after the project search misses; project-bound commands keep requiring a project and return an actionable error for an organization match.

The command layer now chooses an explicit capability helper (resolveProjectBound*, resolveOrgOptional*, or resolveOrgOnly*) instead of implementing project/org lookup itself. This also covers the alert-list --web shortcuts and trace/log target paths that previously bypassed the shared list dispatcher. sentry init intentionally disables fuzzy recovery and keeps its special true-miss behavior of creating a new project. Issue-ID recovery remains a documented non-target-resolution exception.

Test plan

• TZ=UTC pnpm run test:unit — 464 files, 9,963 passed, 14 skipped
• pnpm run lint
• pnpm exec tsc --noEmit
• Same project and organization slug: project wins
• No project and exact organization slug: org-capable commands use the organization
• Project-bound commands still reject an organization-only target
• Explicit <org>/ and <org>/<project> forms bypass bare-target fallback
• Alert --web, dashboard, trace/log, replay, feedback, explore, and init paths use their capability policy

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
cli	Ready	Preview	Sep 28, 2026 10:06am UTC

1 Skipped Deployment

Project	Deployment	Actions	Updated
sentry-local	Skipped		Sep 28, 2026 10:06am UTC

[BYK]

Yes, we should standardise this behaviour as it was always meant to be <project>, <org>/ or <org>/project

[betegon]

Yes — <project>, <org>/, and <org>/<project> remain the canonical forms.

The additional fallback here is deliberately project-first: when someone passes a bare value, we search for a project with that slug first. Only if no project matches and the value exactly matches an accessible organization do we use it as the organization (equivalent to <org>/) and emit a warning. If a project and organization share the same slug, the project wins.

I've also applied that fallback to the --web paths for issue and metric alert lists, which previously bypassed the shared resolver, so the behavior is now consistent there too.

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit b787657. Configure here.}