fix(cli): resolve list/wait projects by repo URL, not directory name (COR-1577)

[juangaitanv]

What & why

corgea list, corgea list --issues, and standalone corgea wait resolved "which project" by the current-directory basename and asked the backend for an exact, case-sensitive match against Project.name. When the checkout directory name differs from the stored project name — the Bank of Hope case, dir dotnet-azure-web-tsb vs project bohappdev/dotnet-azure-web-tsb — three commands misbehaved:

• corgea list --issues → exit 1, "Project with name '…' doesn't exist."
• corgea list → exit 0, silent empty scan table (no error)
• corgea wait (no --scan-id) → exit 1, "Error querying scan list"

This is the residual of COR-1493 (which fixed only the corgea scan → report-results path). Relates to COR-1577.

Approach (CLI-only)

The ticket suggested threading project_id/scan_id, but the listing endpoints accept neither as a query param. Instead this uses an identity the CLI already has and the backend already indexes — the repo URL:

• Resolve the canonical project via GET /api/v1/projects?repo_url=<git remote slug>, then drive the existing name-based query_scan_list / get_scan_issues with the returned canonical name.
• Old-backend safety guard: keep only candidates whose returned repo_url contains the slug. Pre-COR-1426 doghouse ignores the param and returns all projects; the guard rejects that, so resolution falls back cleanly.
• CWD-name fallback when there is no git remote (no regression for non-git checkouts or older backends).
• Drop the now-wrong client-side scan.project == project_name filter.
• Add mutually-exclusive --project-name / --repo override flags to list and wait.
• Replace the silent empty table and the bare "Error querying scan list" with clear miss messages that name the identifier tried.

No doghouse changes, no new persisted CLI state, no new backend query param.

Files

• src/utils/generic.rs — extract_repo_slug (org/repo slug; keeps Azure _git).
• src/utils/api.rs — /projects resolver (resolve_project_by_repo) with the old-backend guard, and the resolve_project orchestrator.
• src/main.rs — --project-name / --repo flags on List/Wait, threaded through.
• src/list.rs — resolve once (non-SCA arm), drop the client filter, clear miss messaging, keep --json stdout clean.
• src/wait.rs — resolve once, build the scan URL from the resolved numeric id, actionable miss message.
• src/scan.rs — semgrep/snyk paths now thread their existing project_name as the override (the wait::run project_id arg was not dead after all). BLAST flow untouched.
• tests/ — 14 new integration tests (list_resolution.rs, wait_resolution.rs) + shared helpers, plus 5 new unit tests.

Testing

• cargo build, cargo clippy --all-targets -- -D warnings, cargo fmt --check: clean.
• cargo test: 456 passed, 0 failed.
• The three baseline failures are reproduced and proven fixed by the new integration tests (mock backend faithful to the doghouse contract).

Notes for reviewers / ship-gates

• On-prem version floor: the repo-URL fix takes effect on doghouse ≥ COR-1426 (2026-06-11). Older instances keep working via the CWD-name fallback (no regression) until upgraded.
• src/scan.rs change is display-only for the semgrep/snyk post-scan results URL; the primary BLAST scan flow uses a separate UploadZipResult and never calls the modified wait::run.
• Manual checks needing live backends (out of scope for this PR's automated tests): list/list --issues/wait on a mismatched checkout against doghouse ≥ COR-1426; the fallback path against a pre-COR-1426 instance; --repo <unknown slug>; the semgrep/snyk results link.

[Ibrahimrahhal]

can we reduce the amount of slop comments

[juangaitanv]

@Ibrahimrahhal cut the comment density down: the diff went from 209 comment lines on 1383 added (15%) to 158 on 1613 (9.8%), and most of what is left is in the tests. src/utils/api.rs and src/utils/generic.rs took the bulk of it — multi-line doc blocks collapsed to one or two lines, inline restatements of the code below them dropped.

I kept three that carry information not in the code: the doghouse normalize_repo_url citation on extract_repo_path, the old-backend /projects guard rationale, and the TCP-RST note on the api.rs test stub.

Also in this push: merged origin/main (conflicts resolved, COR-1639's SHA column ported into the re-indented block), and the five open review threads answered in code — whole-path repo matching, restored project_id threaded into wait, project-name validation before the scan URL, and exit 1 on an unresolved listing miss.

[cursor]

corgea wait <scan-id> still takes the resolver path because the CLI never supplies project_id_override; only post-upload waits satisfy this condition. A hard /projects failure therefore exits at lines 26–35 before check_scan_status, even though both status polling and get_scan_issues use /scan/{id} and need no project. The new wait_with_scan_id_does_not_list_scans test misses this because its stub explicitly serves /projects and only asserts that /scans was skipped. Impact: users with a known scan ID cannot wait during an otherwise unrelated /projects outage. Skip project resolution for any supplied scan ID and derive the canonical project name for the results link from the ScanResponse already fetched by check_scan_status (or otherwise make resolution best-effort on this path); add a test where /projects returns 500 while the scan endpoints succeed.

[cursor]

A successful HTTP response with an invalid or incompatible /projects body is still converted to a clean resolver miss here. resolve_project then falls back to the CWD name (lines 884–893), so a proxy returning HTML or a partially rolled-out schema can make list/wait query a different project instead of surfacing the API failure. This is the same unsafe fallback class as request failures; only an actual 404 or a valid envelope with no exact match should be soft. Propagate this parse error and cover 200 + malformed JSON.

Suggested change

	return Ok(None);
	return Err(format!("Failed to parse /projects response: {e}").into());

[cursor]

This searches only the first response page, but GET /projects?repo_url= is a case-insensitive partial-match endpoint with a default page size of 20 and a total_pages field. Because ProjectsResponse discards the pagination metadata and this request sends neither page nor page_size, 20 substring matches such as acme/api-* can fill page 1 while the exact acme/api candidate is on page 2. The exact-path guard then reports None, recreating the CWD-name miss this PR is intended to fix. Add page/total_pages to the response model and continue requesting pages until an exact repo_url_matches_path candidate is found or all pages are exhausted; add a two-page regression test.

[juangaitanv]

Pushed a cleanup pass on top of the reviewed diff (fb7774a..da0848d) — no force-push, so the existing review threads are intact. No test assertion changed; this is quality only, not new behavior.

Four commits, each reviewable on its own:

1. d77a3e7 — core cleanups

• The api.rs test stub now calls the existing vuln_api_stub::read_http_request / http_response instead of hand-rolling a header-drain loop and a response format!.
• Deleted the never-read ProjectsResponse.status (serde ignores unknown fields, so it bought no validation).
• Extracted resolve_or_exit — the same ~10-line resolver error handler was duplicated verbatim in list.rs and wait.rs.
• list.rs: resolve per branch, dropping Option<ResolvedProject> and its .expect(...); the copy-pasted unresolved-miss block collapses to one copy (the JSON envelope still prints before the error — list_json_miss_is_valid_empty_envelope pins it).
• wait.rs: construct a ResolvedProject directly on the skip path, dropping four .as_ref().map(...) chains. This also fixes a small inconsistency it surfaced: that path fell back to an empty string while resolve_project uses "unknown".
• generic.rs: discover_repo_url and get_repo_info shared 4 identical lines → origin_url.
• resolve_project: dropped the repo_was_explicit flag and the lazy cwd closure.

2. 175f2af — args structs
wait::run took 5 positional params, and repo_override / project_id_override were adjacent and same-typed — transposing them at the scan.rs call sites compiled silently and changed resolution. list::run took 9 and carried #[allow(clippy::too_many_arguments)]. Now ProjectSelector { name, repo } + WaitArgs / ListArgs, and the too_many_arguments allow is gone rather than institutionalized.

3. 0b0abdd — e2e harness dedup (tests only)
spawn_stub and the runner were near-duplicates across list_resolution.rs / wait_resolution.rs, and the Arc<Mutex<Vec<String>>> hit-recording closure was copy-pasted at 7 sites. Now one common::Routes table (an unset field 404s, so "this endpoint is never dialed" tests just leave it out), spawn_recording_http_stub, and run_corgea(subcommand, …).

4. da0848d — list.rs re-indent, alone
The original diff wrapped ~290 lines in a new } else {. The SCA branch now early-returns, putting the rest back at its original indent. Worth reading with git show --ignore-all-space da0848d — it's the removed else, a return;, one brace, and one line rustfmt rejoined.

Verified: cargo build, cargo clippy --all-targets (clean), cargo fmt --check, and the full suite under CI=1 GITHUB_ACTIONS=true (542 passing).

---

Deliberately not done here

• Skipping the /projects round trip in corgea wait <scan-id> (raised twice in review). That call is what produces the id-form URL /project/17/?scan_id=…; without it we fall back to the CWD-basename name-form URL, which reintroduces the COR-1577 bug. Doing it properly means threading ScanResponse.project out of blast::check_scan_status — a behavior change, not a cleanup.
• formatted_repo hand-parsing in list.rs (split('/').nth(3) assumes HTTPS and gets the wrong owner for scp-form remotes). Pre-existing code this PR only re-indented.

Filed as follow-up: COR-1718 — corgea scan and corgea list resolve projects by different keys. The write path (determine_project_name → last URL segment, CWD basename off the worktree root) and the read path (full org/repo, discovered upward) disagree in two verified cases: from a subdirectory, scan names the project after the subdir while list resolves the root project; and for org-qualified projects, scan sends ?project=repo while list resolves org/repo — the shape of this PR's own CANON fixture. Changing where scans land has backend implications well outside COR-1577's read-side scope, so it stays out of this PR.