• Create PR with unit tests

Description

RepoArgs::run writes the repository URL to stdout via println!, even when dispatch_query::repo
selects NdjsonReporter/SilentReporter. This can corrupt NDJSON output (and breaks log-event-only
expectations), undermining the logging parity goal.

Code

pacquet/crates/cli/src/cli_args/repo.rs[R68-79]

+        for url in urls {
+            match open_url(&url) {
+                Ok(()) => {}
+                Err(e) => {
+                    let redacted = redact_url(&url);
+                    R::emit(&LogEvent::Pnpm(PnpmLog {
+                        level: LogLevel::Warn,
+                        message: format!("Could not open browser: {e}"),
+                        prefix: prefix.clone(),
+                    }));
+                    println!("{redacted}");
+                }

Evidence

The compliance checklist requires closing logging parity gaps so output matches the intended pnpm
logger schema. The code routes repo through NdjsonReporter, but still prints to stdout
(println!), which can interleave with NDJSON and violate the log-output contract.

Backfill missing log events in already-ported code (pacquet#347)
pacquet/crates/cli/src/cli_args/dispatch_query.rs[204-213]
pacquet/crates/cli/src/cli_args/repo.rs[68-79]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pacquet repo` prints `redacted` URLs using `println!`, which bypasses the reporter system and can break NDJSON output when `ReporterType::Ndjson` is selected.
## Issue Context
`dispatch_query::repo` explicitly dispatches `RepoArgs::run` with `NdjsonReporter`/`SilentReporter`, so user-visible output should be emitted via `R::emit(...)` (or otherwise gated) rather than unconditional stdout printing.
## Fix Focus Areas
- pacquet/crates/cli/src/cli_args/repo.rs[68-79]
- pacquet/crates/cli/src/cli_args/dispatch_query.rs[204-213]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

merge_missing_peers() records an intersections[peer] entry but, when multiple non-equal ranges
exist, it stores issues[0].wanted_range instead of the actual semver intersection of all required
ranges. This breaks pnpm parity and makes --json output (and conflict/intersection classification)
incorrect for missing peers that have multiple wanted ranges.

Code

pacquet/crates/cli/src/cli_args/peers.rs[R326-335]

+        let ranges: Vec<&str> = issues.iter().map(|i| i.wanted_range.as_str()).collect();
+        let unique: HashSet<&&str> = ranges.iter().collect();
+        if unique.len() == 1 {
+            intersections.insert(peer_name.clone(), issues[0].wanted_range.clone());
+            continue;
+        }
+        let range_owned: Vec<String> = issues.iter().map(|i| i.wanted_range.clone()).collect();
+        if have_common_version(&range_owned) {
+            intersections.insert(peer_name.clone(), issues[0].wanted_range.clone());
+        } else {

Evidence

The Rust code inserts the first wanted range into intersections after only a compatibility check,
while upstream pnpm computes and stores the real intersection string; this makes Rust’s
intersections data wrong whenever multiple distinct wanted ranges intersect to a narrower range.

pacquet/crates/cli/src/cli_args/peers.rs[314-340]
pnpm11/deps/inspection/peers-checker/src/checkPeerDependencies.ts[219-244]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`merge_missing_peers()` currently sets `intersections[peer]` to `issues[0].wanted_range` when multiple wanted ranges exist and are deemed compatible via `have_common_version()`. This does not compute the actual range intersection (often narrower than the first range) and diverges from upstream pnpm which uses semver-range intersection.
## Issue Context
Upstream implementation (`pnpm11/.../checkPeerDependencies.ts`) computes `intersection = safeIntersect(ranges)` and stores that exact intersection string.
## Fix Focus Areas
- pacquet/crates/cli/src/cli_args/peers.rs[314-341]
## Suggested fix approach
- Replace the boolean `have_common_version(...)` pathway with a function that returns `Option<String>` representing the actual intersection string.
- Implement real semver-range intersection behavior (port the minimal logic used by `semver-range-intersect`, or add an internal helper/crate) and set `intersections[peer]` to that computed intersection.
- If intersection cannot be computed or is empty, classify as conflict (push to `conflicts`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

On browser-open failure, pacquet repo prints the (attacker-controlled) repository URL directly to
stdout without stripping control characters. A crafted repository value from package.json or
registry metadata can inject terminal escape/control sequences into user output.

Code

pacquet/crates/cli/src/cli_args/repo.rs[R68-79]

+        for url in urls {
+            match open_url(&url) {
+                Ok(()) => {}
+                Err(e) => {
+                    let redacted = redact_url(&url);
+                    R::emit(&LogEvent::Pnpm(PnpmLog {
+                        level: LogLevel::Warn,
+                        message: format!("Could not open browser: {e}"),
+                        prefix: prefix.clone(),
+                    }));
+                    println!("{redacted}");
+                }

Evidence

The new repo command prints a URL on failure without using the repo’s dedicated terminal
sanitization helper, even though the sanitization helper is explicitly intended to prevent raw
escape sequences from reaching the terminal.

pacquet/crates/cli/src/cli_args/repo.rs[68-79]
pacquet/crates/cli/src/cli_args/sanitize.rs[3-17]
REVIEW_GUIDE.md[30-36]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pacquet repo` prints `redacted` directly via `println!("{redacted}")` on browser-open failure. Repository URLs come from attacker-controlled sources (local manifests / registry metadata), and may include control characters in cases where URL parsing fails and the code falls back to the raw string.
## Issue Context
The CLI already has `cli_args::sanitize::sanitize()` specifically to prevent stored/remote metadata from emitting raw escape sequences to the user's terminal.
## Fix Focus Areas
- pacquet/crates/cli/src/cli_args/repo.rs[68-79]
## Suggested fix approach
- Apply `sanitize()` before printing the fallback URL, e.g. `println!("{}", sanitize(&redacted));`.
- Consider also sanitizing the URL in any other direct-to-terminal output paths added by this command (stdout/stderr).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

try_hosted_shorthand() and try_hosted_url() attempt to strip git+ then git://, but the
second unwrap_or(raw_url) can revert to the original string and undo the git+ strip. This breaks
valid inputs like git+github:owner/repo by preventing hosted-shorthand detection and can make
pacquet repo fail to resolve a repository URL.

Code

pacquet/crates/cli/src/cli_args/repo.rs[R169-172]

+fn try_hosted_shorthand(raw_url: &str, directory: Option<&str>) -> Option<String> {
+    let cleaned =
+        raw_url.strip_prefix("git+").unwrap_or(raw_url).strip_prefix("git://").unwrap_or(raw_url);
+

Evidence

Both helpers compute cleaned such that failing to strip git:// falls back to the original
raw_url, undoing a successful git+ strip and preventing later strip_prefix("github:")/etc
checks from matching.

pacquet/crates/cli/src/cli_args/repo.rs[169-184]
pacquet/crates/cli/src/cli_args/repo.rs[257-263]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`try_hosted_shorthand()` and `try_hosted_url()` compute `cleaned` by chaining `strip_prefix()` calls but fall back to `raw_url` on the second `unwrap_or(...)`, which can reintroduce `git+` and break hosted-shorthand parsing (e.g. `git+github:owner/repo`).
### Issue Context
This affects repository URL normalization for `pacquet repo` when a `repository.url` uses a hosted shorthand with a `git+` prefix.
### Fix
Preserve the already-stripped intermediate value when the `git://` prefix is not present, e.g.:
- `let cleaned = raw_url.strip_prefix("git+").unwrap_or(raw_url);`
- `let cleaned = cleaned.strip_prefix("git://").unwrap_or(cleaned);`
Add a unit test for at least:
- `repository_to_web_url("git+github:owner/repo", None)`
(and the analogous `git+gitlab:` / `git+bitbucket:` forms if supported).
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/repo.rs[169-172]
- pacquet/crates/cli/src/cli_args/repo.rs[257-260]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

parse_allowed_versions() misparses peerDependencyRules.allowedVersions: it splits on the first
@ (breaking scoped names like @scope/pkg) and it stores parent@range literally even though
filtering later matches only by declaring_parent.name, making documented parent@range>peer rules
unreachable and causing false peer-issue failures/exit(1).

Code

pacquet/crates/cli/src/cli_args/peers.rs[R469-494]

+fn parse_allowed_versions(
+    allowed: &HashMap<String, String>,
+) -> (AllowAllMatcher, AllowByParentMatcher) {
+    let mut match_all: HashMap<String, Vec<String>> = HashMap::new();
+    let mut by_parent: HashMap<String, HashMap<String, Vec<String>>> = HashMap::new();
+
+    for (selector, spec) in allowed {
+        if let Some((parent, target)) = selector.split_once('>') {
+            let parent_name = parent.trim().to_string();
+            let target_name = target.trim().to_string();
+            let ranges: Vec<String> = spec.split("||").map(|s| s.trim().to_string()).collect();
+            by_parent
+                .entry(parent_name)
+                .or_default()
+                .entry(target_name)
+                .or_default()
+                .extend(ranges);
+        } else {
+            let target_name = if let Some((name, _version)) = selector.split_once('@') {
+                name.to_string()
+            } else {
+                selector.clone()
+            };
+            let ranges: Vec<String> = spec.split("||").map(|s| s.trim().to_string()).collect();
+            match_all.entry(target_name).or_default().extend(ranges);
+        }

Evidence

The config docs explicitly claim allowedVersions supports parent@range>name, but
parse_allowed_versions() stores the parent selector verbatim and later matching looks up only by
parent **name**, so parent@range can never match. Additionally, splitting a selector using
split_once('@') will turn a scoped selector like @scope/pkg into an empty name key.

pacquet/crates/config/src/workspace_yaml.rs[458-466]
pacquet/crates/cli/src/cli_args/peers.rs[411-448]
pacquet/crates/cli/src/cli_args/peers.rs[469-498]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`peerDependencyRules.allowedVersions` selectors are parsed incorrectly:
- Global selectors with scoped package names (e.g. `@types/node`) are split at the leading `@` and become an empty key.
- Override selectors of the documented form `parent@range>peer` are stored with `parent@range` as the key, but matching later uses only the declaring parent **name**, so these rules can never apply.
This makes configured peer-dependency suppressions ineffective and can cause `pacquet peers` to exit non-zero unexpectedly.
### Issue Context
The config schema explicitly documents `allowedVersions` selectors supporting `parent>name` and `parent@range>name`.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/peers.rs[430-498]
- pacquet/crates/config/src/workspace_yaml.rs[458-466]
- pacquet/crates/cli/src/cli_args/peers/tests.rs[197-233]
### What to change
1. Implement selector parsing that:
- Preserves scoped package names (do not split the leading `@`).
- Supports `name@range` only when there is an `@` **after** the name (e.g. `react@^18`, `@scope/pkg@^2`).
- For `parent@range>peer`, either:
- strip `@range` from the parent key and additionally store the range so matching can check `satisfies(declaring_parent.version, range)`, or
- model a structured key (parent name + optional range) in the matcher map.
2. Update the matching logic in `filter_peer_issues()` accordingly (it currently uses `allow_by_parent.get(&declaring_parent.name)`).
3. Add unit tests:
- `allowedVersions: { "@types/node": "^20" }` should apply.
- `allowedVersions: { "foo@^1.0.0>react": "^18" }` should apply only when declaring parent version satisfies `^1.0.0`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

check_peer_dependencies_from_lockfile() scans every lockfile importer whenever `lockfile_dir !=
dir (workspace), even when recursive` is false, which can report issues from unrelated projects
and causes large workspaces to do full-graph work unexpectedly.

Code

pacquet/crates/cli/src/cli_args/peers.rs[R123-170]

+    let importer_ids: Vec<String> = if recursive || config_has_workspace(lockfile_dir, dir) {
+        lockfile.importers.keys().cloned().collect()
+    } else {
+        vec![resolve_importer_id(lockfile_dir, dir)]
+    };
+
+    let mut result: IssuesByProjects = HashMap::new();
+
+    for importer_id in &importer_ids {
+        let Some(importer) = lockfile.importers.get(importer_id.as_str()) else { continue };
+
+        let mut issues = PeerIssues {
+            bad: HashMap::new(),
+            missing: HashMap::new(),
+            conflicts: Vec::new(),
+            intersections: HashMap::new(),
+        };
+
+        let mut visited = HashSet::new();
+
+        let groups = [
+            (&importer.dependencies, false),
+            (&importer.dev_dependencies, false),
+            (&importer.optional_dependencies, true),
+        ];
+
+        for (dep_map, _is_optional) in &groups {
+            let Some(dep_map) = dep_map else { continue };
+            for (alias, spec) in dep_map {
+                if let Some(key) = spec.version.resolved_key(alias) {
+                    walk_snapshot(&key, snapshots, packages, &[], &mut issues, &mut visited);
+                }
+            }
+        }
+
+        let merged = merge_missing_peers(&issues.missing);
+        issues.conflicts = merged.conflicts;
+        issues.intersections = merged.intersections;
+
+        result.insert(importer_id.clone(), issues);
+    }
+
+    result
+}
+
+fn config_has_workspace(lockfile_dir: &std::path::Path, dir: &std::path::Path) -> bool {
+    lockfile_dir != dir || lockfile_dir.parent().is_none()
+}

Evidence

Peers’ importer selection uses recursive || config_has_workspace(lockfile_dir, dir) where
config_has_workspace is true for lockfile_dir != dir, forcing full-workspace scans by default in
subprojects. In contrast, list resolves a single importer id based on
dir.strip_prefix(lockfile_dir) even when workspace_dir is set, indicating the intended
non-recursive behavior is single-importer scope.

pacquet/crates/cli/src/cli_args/peers.rs[112-170]
pacquet/crates/cli/src/cli_args/list.rs[104-136]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
In `check_peer_dependencies_from_lockfile()`, importer selection expands to **all** importers when `config_has_workspace(lockfile_dir, dir)` is true. Since `config_has_workspace()` returns true whenever `lockfile_dir != dir`, running `pacquet peers` from a workspace subdirectory (without `--recursive`) still scans and reports across the entire workspace.
This is both a performance regression (full-graph traversal on big workspaces) and a correctness/UX issue (failures caused by unrelated workspace projects).
### Issue Context
Other CLI commands (e.g. `list`) compute a single importer id from `dir` vs `lockfile_dir` and operate on that importer unless recursion is explicitly requested.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/peers.rs[112-182]
- pacquet/crates/cli/src/cli_args/list.rs[104-136]
### What to change
1. Remove the implicit workspace fan-out from `check_peer_dependencies_from_lockfile()`.
- Use `lockfile.importers.keys()` only when `recursive` is true.
- Otherwise, operate only on `resolve_importer_id(lockfile_dir, dir)` (optionally falling back to root importer if missing, similar to `list`).
2. (Optional perf improvement) If recursive mode still needs to scan all importers, consider de-duplicating traversal work across importers (e.g., cache per-snapshot results) to avoid repeating the same graph walk N times.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

open_url() executes xdg-open/open via PATH and passes the attacker-controlled URL as the first
argument without --, allowing PATH hijacking (running a repo-provided xdg-open) and option
injection when the URL starts with -. In environments where pacquet runs with a project-influenced
PATH (e.g. pnpm run), this can become arbitrary code execution under the user account.

Code

pacquet/crates/cli/src/cli_args/repo.rs[R324-333]

+fn open_url(url: &str) -> miette::Result<()> {
+    let result = {
+        #[cfg(target_os = "linux")]
+        {
+            std::process::Command::new("xdg-open").arg(url).spawn()
+        }
+        #[cfg(target_os = "macos")]
+        {
+            std::process::Command::new("open").arg(url).spawn()
+        }

Evidence

The PR introduces a new open_url() that executes PATH-resolved programs with attacker-controlled
URL arguments; REVIEW_GUIDE flags this class as security-sensitive, and existing CLI code
demonstrates a safer executable-resolution pattern.

pacquet/crates/cli/src/cli_args/repo.rs[324-333]
REVIEW_GUIDE.md[30-59]
pacquet/crates/cli/src/cli_args/exec.rs[160-168]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`open_url()` spawns `xdg-open`/`open` by program name (PATH resolution) and passes an untrusted URL without an end-of-options marker. This permits PATH hijacking (e.g., a repo-controlled `xdg-open` earlier in PATH) and option injection when the URL begins with `-`.
## Issue Context
- REVIEW_GUIDE.md explicitly calls out executable resolution and command-injection surfaces and treats manifest/registry metadata as attacker-controlled.
- Other CLI code (e.g. `exec`) explicitly resolves executables with `which` rather than relying on `Command::new("name")`.
## Fix Focus Areas
- pacquet/crates/cli/src/cli_args/repo.rs[324-333]
## Suggested implementation direction
- Resolve opener to an absolute path instead of relying on PATH at spawn time:
- macOS: prefer `/usr/bin/open`.
- Linux: attempt known paths (e.g. `/usr/bin/xdg-open`) and/or use `which::which("xdg-open")` as a fallback.
- If resolution fails or resolves inside the current workspace / `node_modules/.bin`, do not execute it; print the URL instead.
- Add an end-of-options marker when supported:
- `xdg-open -- <url>` and `open -- <url>`.
- Keep Windows on `ShellExecuteW` as-is.
- Consider refactoring `docs.rs` + `repo.rs` to share a single hardened helper to avoid repeating the risky pattern.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

try_hosted_shorthand()/build_hosted_browse_url() build the browse URL from parts[..2], so
gitlab:group/subgroup/repo becomes https://gitlab.com/group/subgroup (wrong repository). This
breaks nested-group GitLab repos, which are common in practice.

Code

pacquet/crates/cli/src/cli_args/repo.rs[R186-205]

+    let fragment = extract_fragment(cleaned);
+    let path_clean = path.split(&['#', '?'][..]).next().unwrap_or(path).trim_end_matches('/');
+    let parts: Vec<&str> = path_clean.split('/').collect();
+    if parts.len() < 2 {
+        return None;
+    }
+
+    let hosted_base_url = &hosted.base_url;
+    let browse_path = format!("{hosted_base_url}/{}", parts[..2].join("/"));
+
+    let browse_url = if let Some(dir) = directory {
+        let default_branch = hosted.default_branch;
+        format!("{browse_path}/tree/{default_branch}/{}", dir.trim_start_matches('/'))
+    } else if let Some(branch) = fragment {
+        format!("{browse_path}/tree/{branch}")
+    } else {
+        browse_path
+    };
+
+    Some(browse_url)

Evidence

The repo URL builder slices hosted shorthand paths to the first two segments, which necessarily
drops additional segments for nested GitLab groups. Pacquet’s existing hosted-git shortcut parsing
instead splits at the last '/', preserving the full owner/group path before the repo name.

pacquet/crates/cli/src/cli_args/repo.rs[186-205]
pacquet/crates/cli/src/cli_args/repo.rs[293-311]
pacquet/crates/resolving-git-resolver/src/hosted_git.rs[180-207]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pacquet repo` truncates hosted shorthand paths to the first two segments when building web URLs. For GitLab shorthands with nested groups (e.g. `gitlab:group/subgroup/repo`), this drops the actual repo name and opens the wrong page.
### Issue Context
GitLab owner paths can contain multiple `/`-separated segments. The code currently assumes `owner/repo` by taking `parts[..2]`.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/repo.rs[169-206]
- pacquet/crates/cli/src/cli_args/repo.rs[287-312]
### Suggested fix
- Replace the `parts[..2]` logic with a split at the **last** `/`:
- `let (owner_path, repo) = path_clean.rsplit_once('/')?;`
- `browse_path = format!("{base}/{owner_path}/{repo}")` (and trim `.git` on `repo` as needed).
- Apply the same logic in both `try_hosted_shorthand()` and `build_hosted_browse_url()` so github/gitlab/bitbucket shorthands behave consistently.
- Add a unit test for `gitlab:group/subgroup/repo` (and optionally `github:org/team/repo` if you intend to support it similarly).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

try_user_repo_shorthand() routes git@... repository values to try_hosted_url(), but
try_hosted_url() uses url::Url::parse, which cannot parse SCP-style SSH URLs like
git@github.com:owner/repo.git. As a result, pacquet repo will incorrectly fail to resolve
repository URLs for a common real-world repository format.

Code

pacquet/crates/cli/src/cli_args/repo.rs[R257-263]

+fn try_hosted_url(raw_url: &str, directory: Option<&str>) -> Option<String> {
+    let cleaned =
+        raw_url.strip_prefix("git+").unwrap_or(raw_url).strip_prefix("git://").unwrap_or(raw_url);
+
+    let parsed = url::Url::parse(cleaned).ok()?;
+    let host = parsed.host_str()?;
+

Evidence

try_user_repo_shorthand() explicitly routes git@... inputs to try_hosted_url(), but
try_hosted_url() relies on url::Url::parse, which does not accept scp-like SSH syntax, so the
resolution necessarily returns None for these common repository URLs.

pacquet/crates/cli/src/cli_args/repo.rs[208-213]
pacquet/crates/cli/src/cli_args/repo.rs[257-263]
pacquet/crates/resolving-git-resolver/src/hosted_git.rs[270-287]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pacquet repo` intends to support SSH repository URLs, but the scp-like form (`git@github.com:owner/repo.git[#branch]`) is not a valid hierarchical URL and therefore fails `url::Url::parse(...)` in `try_hosted_url()`. This makes `repository_to_web_url()` return `None` for common repository values.
### Issue Context
The code already checks `cleaned.starts_with("git@")` and routes to `try_hosted_url()`, so the intent is to support this shape; the parser choice is what blocks it.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/repo.rs[208-213]
- pacquet/crates/cli/src/cli_args/repo.rs[257-285]
### Suggested fix
1. In `try_hosted_url()`, add an explicit parser for scp-like SSH URLs:
- Accept optional `git+` prefix.
- Parse `git@<host>:<owner>/<repo>(.git)?` and optional `#<branch>`.
- For supported hosts (github.com/gitlab.com/bitbucket.org), convert to `https://<host>/<owner>/<repo>` and then append `/tree/<branch>` or `/tree/<default_branch>/<directory>` as appropriate.
2. Add unit tests covering at least:
- `git@github.com:test/pkg.git` -> `https://github.com/test/pkg`
- `git@github.com:test/pkg.git#main` -> `https://github.com/test/pkg/tree/main`
- directory handling if present (if you decide to support it for this syntax).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

open_url() uses Command::status() on Linux/macOS, which blocks pacquet repo until
xdg-open/open exits. This can make the command appear stuck/slow on systems where the opener
waits, and is inconsistent with the existing docs command’s non-blocking .spawn() behavior.

Code

pacquet/crates/cli/src/cli_args/repo.rs[R397-407]

+fn open_url(url: &str) -> std::io::Result<()> {
+    #[cfg(target_os = "linux")]
+    {
+        let status = std::process::Command::new("xdg-open").arg(url).status()?;
+        if status.success() { Ok(()) } else { Err(std::io::Error::other("xdg-open failed")) }
+    }
+    #[cfg(target_os = "macos")]
+    {
+        let status = std::process::Command::new("open").arg(url).status()?;
+        if status.success() { Ok(()) } else { Err(std::io::Error::other("open failed")) }
+    }

Evidence

The new repo implementation waits on the opener process via .status() on Linux/macOS, while the
existing docs command uses .spawn() (non-blocking), demonstrating an inconsistency and showing
how to avoid blocking.

pacquet/crates/cli/src/cli_args/repo.rs[397-407]
pacquet/crates/cli/src/cli_args/docs.rs[87-97]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pacquet repo` blocks on Linux/macOS because it uses `Command::status()` to launch the platform opener. This waits for the opener process to exit, which can delay completion significantly depending on the opener implementation.
### Issue Context
`pacquet docs` already launches the browser in a non-blocking way (`spawn()`), suggesting the intended behavior is to fire-and-forget.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/repo.rs[397-407]
- pacquet/crates/cli/src/cli_args/docs.rs[87-97]
### Suggested fix
- On Linux/macOS, replace `.status()?` with `.spawn()?` and treat successful spawn as success.
- Keep the existing error path that logs/prints the redacted URL when spawning fails.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

get_repo_url_from_registry() forces full_metadata: true, which downloads and parses a larger
packument than needed just to read a version’s repository field. This increases latency/bandwidth
and CPU/memory usage per package lookup (especially noticeable when passing multiple packages).

Code

pacquet/crates/cli/src/cli_args/repo.rs[R126-136]

+    let outcome = fetch_full_metadata(
+        resolved_name,
+        &FetchFullMetadataOptions {
+            registry: &registry,
+            http_client,
+            auth_headers: &config.auth_headers,
+            full_metadata: true,
+            etag: None,
+            modified: None,
+            retry_opts: *retry_opts,
+        },

Evidence

The new command explicitly opts into full packument fetching. The fetcher implementation in-repo
documents that abbreviated metadata exists and that the primary differences are fields unrelated to
opening repository URLs, indicating a clear opportunity to reduce work on this code path.

pacquet/crates/cli/src/cli_args/repo.rs[126-153]
pacquet/crates/resolving-npm-resolver/src/fetch_full_metadata.rs[1-18]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`pacquet repo <pkg...>` always requests full registry metadata (`full_metadata: true`). For this command, we only need the selected version’s `repository` field, so fetching the abbreviated packument should be sufficient and cheaper.
### Issue Context
The resolver already supports abbreviated vs full metadata, and the abbreviated form is documented (in-repo) as primarily omitting fields like `time`, `_npmUser`, and `dist.attestations`.
### Fix Focus Areas
- pacquet/crates/cli/src/cli_args/repo.rs[126-136]
- pacquet/crates/resolving-npm-resolver/src/fetch_full_metadata.rs[1-18]
### Suggested fix...