[joseph-sentry]

we're adding more types of failures on repo lookups:

• missing repo
• unconnected account (there's no integration that matches the provided SCM org)

this is so when the seer agent calls these tools with these misconfigurations we can offer accurate information to the user:

• missing repo: are you sure your integration has access to this repo, or is the agent using the wrong slug
• unconnected account: please make sure to install the app on this org, or again correct the agent's call arg

[billyvg]

🤖 Classifier normalizes names more loosely than the lookup, so misses get wrong reasons

_name_segments strips whitespace around each / and casefolds. _find_repository does neither: it matches name exactly and compares a url suffix. So a lookup that misses only because of how the name is written still gets a confident failure reason, and the reason is wrong:

• GitLab display name without the spaces. Take My Group/Sub/App, where Sentry stores My Group / Sub / App with URL path my-group/sub/app. _find_repository misses it, because Q(name=...) is exact and the URL doesn't end with that string. Here, ["my group", "sub", "app"] starts with the integration name My Group / Sub, so the response is repo_not_in_sentry, but the repo is in Sentry. This input is realistic. Seer's own _normalize_repo_full_name (seer/automation/explorer/tools/utils.py) says the LLM passes the stripped form, and that Seer only recovers from it when it already has an external_id hint.
• Host-qualified name. Take github.com/acme-labs/app. url__iendswith matches the repo as a candidate, but the Python check rejects it. Then ["github.com", "acme-labs", "app"] doesn't start with acme-labs, so the response is scm_account_not_connected. The agent would then ask the user to install the app on an account where it's already installed, for a repo Sentry already has. That is the misleading advice this PR is meant to prevent.

Fix: normalize the requested name once and use the result for both the lookup and the classification.

• Whitespace: _find_repository could also try Q(name__iexact=" / ".join(segments)), since GitLab's name_with_namespace always joins with /, and compare segment-normalized names in its Python check.
• Hosts: strip a leading scheme, and a first segment equal to a connected integration's host, before the lookup.
• Smaller fix: if that's out of scope here, make _repository_lookup_failure return None when the first segment is a connected integration's host. In that case the reason isn't actually known, and None matches the function's "when it's known" contract.

_{Written by an AI agent and included in this review by its author.}

[billyvg]

🤖 connected_accounts gives GitLab display names, duplicates and no provider

The description says this list should help the agent correct its call argument. As written, it doesn't help much:

• GitLab names: for GitLab, integration.name is the group's display name (My Group / Sub). It isn't the path (my-group/sub), which is what get_repository_definition returns as owner on success and what a retry should pass. An agent that builds My Group / Sub/app from this list still misses in _find_repository.
• Duplicates: an account appears once per integration. The new test at test_tools.py:3228 compares a set because the list holds acme-labs three times. GitHub and Cursor Origin connected to the same account is a plausible real setup.
• No provider: with the provider dropped, GitHub's acme-labs and Cursor Origin's acme-labs look the same.

Fix: report the prefix the agent should pass: the URL path for GitLab, and integration.name elsewhere. Don't derive it from domain_name for Cursor Origin, whose path is codebase/<slug>. Then deduplicate the list, add the provider if you want it, and make the test assert the exact list rather than a set.

_{Written by an AI agent and included in this review by its author.}

[billyvg]

🤖 GitLab connected_accounts gives the agent a display name it can't reuse

connected_accounts lists integration.name. For GitLab that is the group's full_name, a display name like My Group / Sub (see gitlab/integration.py:799). The point of this field is to let the agent fix its slug and retry. The form it can retry with is the URL path (my-group/sub): RepositoryDefinitionResponse builds owner/name from get_repo_url_path, and _find_repository matches display names only by exact, case-sensitive name=. So My Group / Sub/app and my group / sub / app both still miss.

For GitHub, GHE and Cursor Origin, name already equals the path segment, so only GitLab is affected. You can't simply switch every provider to the path taken from domain_name, though. Cursor Origin's domain_name is https://cursor.com/codebase/<slug>, so the generic parse on L944 yields codebase/<slug> there. That also means the URL-path branch of _is_under_account never matches for Cursor Origin, which is classified through its name alone. Options:

• report the group path for GitLab (metadata["domain_name"].partition("/")[2], the same parse GitlabIntegration.source_url_matches uses), or
• report both forms, e.g. connected_accounts=[{"name": ..., "path": ...}], so the user-facing message can show the display name and the agent can retry with the path.

Seer doesn't read this field yet (no report_failure_reason callers on seer main), so the shape is still cheap to change.

_{Written by an AI agent and included in this review by its author.}

[billyvg]

🤖 Not-connected GitLab cases repeat test_failure_for_each_provider

These two cases don't catch any mutant that test_failure_for_each_provider misses. Its GitLab subtest already checks my-group/sub-2/app → scm_account_not_connected. That fails on the same wrong implementations these would catch: comparing only the first segment, dropping the last account segment, or a plain startswith on the joined strings. The two repo_not_in_sentry cases above them do add coverage (the display-name form tests .strip(), and nested/app tests deeper repos), so keep those and drop this loop.

The same applies to the final other-org/app assertion in test_failure_checks_every_connected_account (L3230–3231). That test earns its place with the first assertion, which fails if only one integration is checked.

_{Written by an AI agent and included in this review by its author.}