fix(resolve): guide users to org/project instead of silencing the auto-detect error (#1155)

## Why

Follow-up to #1149 based on review feedback: **"Could not auto-detect
organization and project" was being silenced, which hid the signal AND
skipped the underlying UX fix.** We keep these errors around to learn
where users get stuck — so the right move is to help users succeed *and*
keep the error visible to measure impact.

CLI-3B: ~2000 users.

## What changed

**1. Sole-account auto-select (helps every command, zero risk)**
`resolveOrgAndProject` gains a final cascade step: when an authenticated
account has exactly **one** accessible org with exactly **one** project,
that pair is the only possible answer, so it's returned instead of
`null`. This is strictly additive — callers that depend on a `null`
return (notably `event view`'s cross-org search) are unaffected, since
it only ever turns a `null` into a uniquely-determined target.

**2. Interactive picker (TTY)**
On a failed auto-detect, `guideOrgProjectFailure` prompts the user to
choose an org then a project, and saves the choice as the default (so
they're not asked again). Gated on **both** stdin and stdout being TTYs,
so piped/`--json` invocations never block on a prompt.

**3. Enriched error**
Authenticated users who still can't be resolved get a `ContextError`
listing their accessible orgs (copy-pasteable), instead of the generic
"run `sentry org list`" guidance shown to logged-out users.

**4. Un-silence `ContextError`**
Reverted the `classifySilenced` `ContextError` branch (and the now-dead
`recordSilencedError` resource attribute) so its volume stays visible —
that volume is the signal for whether the UX changes above actually
work.

## Wiring

`guideOrgProjectFailure` is invoked on the auto-detect failure path of
`resolveOrgProjectTarget`, `resolveTargetsFromParsedArg` (backs `issue
list`), and `trace-target`. The fallback is kept **separate** from
`resolveOrgAndProject` (rather than wrapping it) so command tests that
mock the resolver — and rely on its `null` return — keep working; the
guide only runs on the explicit failure path.

Upload commands
(`sourcemap`/`debug-files`/`proguard`/`code-mappings`/`dart-symbol-map`)
get the sole-account auto-select for free via `resolveOrgAndProject`;
their interactive-picker/enriched-error wiring can follow up (they're
usually non-interactive CI runs with DSN/config context).

## Tests

- `resolveOrgProjectOrGuide`: sole-org/project auto-select, multi-org
enriched `ContextError`, unauthenticated generic `ContextError` (no
org-list call).
- Updated `classifySilenced` / `recordSilencedError` / telemetry tests
to assert `ContextError` is now **captured**, not silenced.
- Updated trace/span resolver tests for the new fallback path.
- Full `test/lib` + `test/commands` suites green (7964 passing); lint +
typecheck clean.

Author: BYK

.lore.md

@@ -474,9 +474,15 @@
 <!-- lore:019e5ae3-dee8-7d8c-97cb-69a50bf223ed -->
 * **Always create a dedicated branch when updating fossilize versions**: When a new version of fossilize is released, always create a branch named \`chore/fossilize-{version}\` tracking origin/main, update the dependency, remove any functionality now handled natively by fossilize (e.g., \`stripCachedNodeBinaries()\` removed in 0.7.0), verify the build succeeds, then commit with \`chore: update fossilize to X.Y.Z\`. Follow this exact pattern: branch → update dep → remove superseded code → build verify → commit → PR.
 
+<!-- lore:019f60d4-72d1-703c-9c8f-ee44d9e61217 -->
+* **Always Directs to Resolve Merge Conflicts and Ensure Compatibility**: The user consistently directs the assistant to resolve merge conflicts, ensure compatibility, and verify code changes before merging. This includes rebasing branches, resolving conflicts, and verifying code changes. The user also emphasizes the importance of backwards and forwards compatibility during transitions and releases.
+
 <!-- lore:019e51da-a4fd-75f7-85e9-6627f83e74f4 -->
 * **Always explore e2e test infrastructure thoroughly before debugging or modifying tests**: When approaching e2e test work, always explore the full infrastructure before making changes: \`test/e2e/\` (14 files: api, auth, bundle, completion, delta-upgrade, event, issue, library, log, multiregion, project, skill-eval, telemetry-exit, trace), \`test/fixture.ts\` (getCliCommand, runCli, createE2EContext), \`test/helpers.ts\` (useTestConfigDir, useEnvSandbox, resetHostScopingState, mintSntrysToken, extractFetchUrl), \`test/mocks/\` (server.ts, routes.js, multiregion.ts), \`src/bin.ts\`, \`src/cli.ts\`. Key: \`getCliCommand()\` returns \`\[SENTRY\_CLI\_BINARY]\` if set, else \`\[process.execPath, 'run', 'src/bin.ts']\`. \`createE2EContext.run()\` sets \`SENTRY\_AUTH\_TOKEN: ''\`, \`SENTRY\_TOKEN: ''\`, \`SENTRY\_CLI\_NO\_TELEMETRY: '1'\`. \`test:e2e\` runs without \`--isolate --parallel\`. Map full infrastructure before proposing fixes.
 
+<!-- lore:019f60d5-d995-782e-a4e1-5fe53abb792c -->
+* **Always fetchable from the base repo with github**: User stated always fetchable from the base repo with github.
+
 <!-- lore:019f3852-932f-7ff6-9192-c9efc7457b18 -->
 * **Always fix root causes and add preventive safeguards together**: When the user identifies a recurring or accumulated problem (e.g., 61 stale PR previews bloating gh-pages), they direct: (1) fix the immediate root cause, (2) port or add automation to prevent recurrence (e.g., on-PR-close cleanup), and (3) add a scheduled safety-net sweep as a belt-and-suspenders measure. Similarly with code bugs: they want the bug fixed AND the underlying gap addressed. Never just patch the symptom — always pair the fix with structural prevention. This applies to CI/CD workflows, dependency issues, and code correctness problems alike.
 
@@ -519,6 +525,9 @@
 <!-- lore:019f60a3-616e-77a1-bbd2-7376005e41df -->
 * **Always requests a thorough review before merging PRs**: The user consistently requests detailed reviews of pull requests (PRs) before merging them. This includes scrutinizing changes, verifying git status is clean, and checking test coverage. The user also focuses on specific areas such as error handling, edge cases, and code correctness. Additionally, the user often performs multiple review passes, requesting objective and critical reviews to ensure high-quality code changes.
 
+<!-- lore:019f60d4-cf8a-7213-a62e-41e6b23b80e0 -->
+* **Always requests exhaustive and detailed research**: The user consistently requests thorough and precise investigations into specific aspects of the codebase, infrastructure, or related tools. They emphasize the need for exhaustive research, often specifying that no code should be written and that findings should be detailed, including file paths, line numbers, and config values. This pattern is evident across multiple sessions, where the user asks for detailed inventories, code reviews, and investigations into various components such as release infrastructure, build processes, and versioning mechanisms.
+
 <!-- lore:019e56f4-d4d9-7d15-b729-2f11a05dd23d -->
 * **Always research technical approaches thoroughly before implementation**: When facing a significant technical decision or migration, the user consistently requests deep research into multiple approaches before writing any code. This includes: fetching specific upstream documentation/source files (e.g., BUILDING.md, configure.py), identifying concrete flags/options, estimating build times, and evaluating cross-compilation feasibility. The user wants tradeoffs between paths laid out explicitly. Only after research is complete does implementation begin. When presenting research, include specific flags, URLs, estimated costs (time/size), and platform constraints.
 
@@ -597,6 +606,12 @@
 <!-- lore:019f609c-b01f-79db-ad40-f0e299775799 -->
 * **Never exceed the terminal width (it would wrap into a broken layout otherwise)**: Never exceed the terminal width (it would wrap into a broken layout otherwise). This is a standing directive to ensure readable output.
 
+<!-- lore:019f60d6-3f67-78ee-9e4a-ba550489b4d2 -->
+* **Never target the same path**: User stated never target the same path.
+
+<!-- lore:019f60d6-b41b-7bc0-9b92-3c9e391be71b -->
+* **Never throws - errors are caught and reported to Sentry**: User stated Never throws - errors are caught and reported to Sentry.
+
 <!-- lore:019efaea-f5bc-7140-abd0-996eb16f4d5d -->
 * **Never treat incomplete operations as successful — always surface silent failures**: When reviewing code, the user explicitly asserts that incomplete operations must never report success. Examples from \`debug-files upload\`: \`not\_found\` after deadline is a failure (exit 1), not success (exit 0). Symlink cycles must not hang silently. Missing requested IDs must be surfaced. Any failure path that silently exits 0 or produces no diagnostic is a blocker.
 

src/lib/command.ts

@@ -57,6 +57,7 @@ import {
 } from "./formatters/output.js";
 import { isPlainOutput } from "./formatters/plain-detect.js";
 import { GLOBAL_FLAGS } from "./global-flags.js";
+import { setInteractivePromptsAllowed } from "./interactive-prompts.js";
 import {
   LOG_LEVEL_NAMES,
   type LogLevelName,
@@ -704,6 +705,10 @@ export function buildCommand<
       }
     }
 
+    // Suppress interactive prompts (e.g. the org/project picker) in JSON mode so
+    // a prompt never blocks a scripted run or interleaves with stdout JSON.
+    setInteractivePromptsAllowed(!cleanFlags.json);
+
     const stdout = (this as unknown as { stdout: Writer }).stdout;
 
     // Reset per-invocation state

src/lib/error-reporting.ts

@@ -4,10 +4,15 @@
  * Provides two things:
  *
  * 1. **Silencing rules** — `OutputError`, network failures (offline/DNS/proxy),
- *    `ContextError` (a required value the user omitted), `AuthError` (expected
- *    auth states the user must act on), 401–499 `ApiError`, and 400 `ApiError`s
- *    that report an unparseable user search query are not sent to Sentry as
- *    issues. A `cli.error.silenced` metric preserves volume + user/org context.
+ *    `AuthError` (expected auth states the user must act on), 401–499 `ApiError`,
+ *    and 400 `ApiError`s that report an unparseable user search query are not
+ *    sent to Sentry as issues. A `cli.error.silenced` metric preserves volume +
+ *    user/org context.
+ *
+ *    `ContextError` (a required value the user omitted) is deliberately NOT
+ *    silenced: its volume is the signal driving auto-detection/UX improvements
+ *    (e.g. single-org auto-select, the interactive picker), so it must stay
+ *    visible (CLI-3B).
  *
  * 2. **Grouping tags** — enriches every error event with `cli_error.*` tags
  *    that Sentry's server-side fingerprint rules use for stable grouping.
@@ -47,7 +52,6 @@ import {
  */
 type SilenceReason =
   | "output_error"
-  | "context_missing"
   | "auth_expected"
   | "api_user_error"
   | "network_error";
@@ -70,16 +74,14 @@ export function classifySilenced(error: unknown): SilenceReason | null {
   if (isNetworkError(error)) {
     return "network_error";
   }
-  // A ContextError always means the user omitted a required value (no
-  // org/project could be resolved, a required ID was not provided, etc.). It is
-  // never a CLI bug — unlike ResolutionError, where a *provided* value that
-  // can't be matched may signal a product/access issue worth observing. There
-  // is nothing per-instance to investigate, so silence the whole class; the
-  // `cli.error.silenced` metric (keyed by `error_class` + `resource`) preserves
-  // the volume and which value was missing. (CLI-3B: ~2000 users.)
-  if (error instanceof ContextError) {
-    return "context_missing";
-  }
+  // A ContextError means the user omitted a required value (no org/project
+  // could be resolved, a required ID was not provided, etc.). It is NOT
+  // silenced: the volume of these is the signal we use to drive auto-detection
+  // and UX improvements (single-org auto-select, the interactive picker, the
+  // enriched error). Silencing it hid that signal AND skipped the fix, so it
+  // stays captured (CLI-3B). The accompanying `resolveOrgProjectOrGuide`
+  // changes aim to drive this volume down by helping users succeed instead.
+  //
   // All AuthError reasons are expected auth states the user must act on, not
   // CLI bugs: `not_authenticated` (no token), `expired` (token aged out), and
   // `invalid` (a bad/insufficiently-scoped token the user supplied). `invalid`
@@ -112,12 +114,6 @@ function recordSilencedError(error: unknown, reason: SilenceReason): void {
   if (error instanceof AuthError) {
     attributes.auth_reason = error.reason;
   }
-  // Preserve which required value was missing so the silenced-volume metric
-  // keeps sub-grouping context (e.g. "Organization and project" vs "Event ID").
-  // ContextError resources are a small fixed set, so cardinality stays low.
-  if (error instanceof ContextError) {
-    attributes.resource = error.resource;
-  }
 
   try {
     Sentry.metrics.distribution("cli.error.silenced", 1, { attributes });

src/lib/interactive-prompts.ts

@@ -0,0 +1,29 @@
+/**
+ * Process-wide gate for interactive prompts.
+ *
+ * Commands that emit machine-readable output (`--json`, or `SENTRY_OUTPUT_FORMAT=json`)
+ * must never block on an interactive prompt or interleave prompt UI with JSON on
+ * stdout. The command wrapper disables prompts for such runs via
+ * {@link setInteractivePromptsAllowed}, and prompt sites (e.g. the org/project
+ * picker in `resolve-target.ts`) consult {@link interactivePromptsAllowed}
+ * before showing a prompt.
+ *
+ * Defaults to `true` so code paths that run outside the command wrapper (tests,
+ * library callers) fall back to their own TTY checks rather than being silently
+ * blocked.
+ */
+
+let allowed = true;
+
+/**
+ * Enable or disable interactive prompts for the current command run. Called by
+ * the command wrapper with `false` when JSON output is active.
+ */
+export function setInteractivePromptsAllowed(value: boolean): void {
+  allowed = value;
+}
+
+/** Whether interactive prompts are currently permitted. */
+export function interactivePromptsAllowed(): boolean {
+  return allowed;
+}