GeezerVison

BugBot review

Generated by Claude Code

[agent] coverage failed on ab0ffcb in -p socket-patch-cli --test in_process_edge_cases (job 114727527547). This is the intermittent failure tracked in #1416: the same binary failed on #1410 and passed on a re-run of the same SHA. This PR changes only the Composer global-home fallback in crawlers/composer_crawler.rs and its core tests, and doesn't touch that binary. Every other test target in the job passed, and all Composer tests pass locally. No fix exists yet; #1416 is waiting for someone with log access to get the panic text (the log tool here returns only the last 5,000 of ~16,000 lines). Re-running the failed job once.

Generated by Claude Code

Ready for review (burn-down agent)

• Head: ab0ffcb
• CI: 36/36 non-skipped checks green (50 skipped by path filters), after one re-run of the coverage job's CI flake: coverage job fails intermittently in vendor / in_process_edge_cases #1416 intermittent in_process_edge_cases failure, which this PR doesn't touch. Mergeable, no conflicts, no CHANGELOG.md change.
• Bugbot: reviewed ab0ffcb, no issues found; no open review threads.
• Reviewer focus: crawlers/composer_crawler.rs. The global-home fallback now probes the XDG Composer home before ~/.composer, matching Composer 2 (fixes Composer global-home fallback checks ~/.composer before the XDG home, so scan -g finds no Composer 2 global packages when a stale ~/.composer exists and composer isn't on PATH #586).

Generated by Claude Code

Final review brief

What it does: Fixes #586. When neither COMPOSER_HOME nor composer global config home answers, socket-patch now probes the global Composer home in Composer 2's order. On an XDG system it checks $XDG_CONFIG_HOME/composer (or ~/.config/composer) before ~/.composer. An XDG system is one where any XDG_* env var is set or /etc/xdg exists, the same test as Composer's useXdg(). Before this, a stale ~/.composer beat the real XDG home.

Risk: low. It only changes the last-resort fallback. Windows ordering is the same as before. On non-XDG systems, ~/.config/composer is still probed last, so nothing that used to be found is lost.

Look here:

• composer_crawler.rs#L386-L391:`` the candidate list is built on run_blocking because it stats `/etc/xdg`
• composer_crawler.rs#L421-L434:``` the XDG decision and uses_xdg()
• composer_crawler.rs#L454-L473:```` the XDG candidate goes first, an empty XDG_CONFIG_HOME falls back to `/.config`, a relative one is skipped, and `/.config/composer` is de-duplicated
• covgap_crawlers_composer_crawler.rs#L184-L250:````` the two new Composer global-home fallback checks ~/.composer before the XDG home, so scan -g finds no Composer 2 global packages when a stale ~/.composer exists and composer isn't on PATH #586 regression tests, which use a serial env guard

Verified:

• Read the full diff and compared it with Composer 2's Factory::getHomeDir().
• Local test runs at ab0ffcb: composer_crawler unit tests 38/38, covgap_crawlers_composer_crawler 5/5, global_probe_spawn_e2e 10/10, crawler_composer_e2e 33/33.
• Both new regression tests fail against the main-branch composer_crawler.rs.
• CI ci-ok and clippy are green on ab0ffcb, and Bugbot is clean.
• No unresolved threads, and CHANGELOG.md is untouched.

Changes I made: none.

Open questions (non-blocking):

1. uses_xdg() reads the real process env and /etc/xdg, not the injected var closure. Production is unaffected, and the tests call composer_home_candidates_for(.., xdg) with an explicit flag instead.
2. There are two intended differences from Composer. A relative XDG_CONFIG_HOME is skipped, where Composer would resolve it against its cwd. With HOME unset, the code still probes an absolute XDG home, where Composer would throw.

Auto-merge is armed, so approving sends this straight to the merge queue.

Generated by Claude Code