3 Commits

Include renames

Author	SHA1	Message	Date
morlutoandCursor Agent	a7ec7271d6	fix(setup): preserve client configuration and ownership (#9894) ... * fix(config): preserve client settings during launcher refresh * fix(setup): retain parsed client launcher ownership * fix(uninstall): retain resource cleanup diagnostics * test(setup): keep temporary paths inside the workspace root Resolve setup fixtures through the test workspace path helper so joined paths stay under the temporary root. * test(setup): validate temporary paths before filesystem calls Contain workspace children and the symlink target before creating the launcher alias so a temporary path cannot leave its root. * test(setup): expect owned command identity in BOM registration status Aligned client registration status includes command_identity. The BOM read-back compared the status without that field, so an owned launcher failed the equality check. --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>	2026-11-11 04:10:32 -05:00
4 people	7baed55130	fix(doctor): probe providers with the selected client's registration environment (#9108) ... * fix(doctor): probe providers with the selected client's registration environment rea doctor read provider settings only from the terminal running it. A client registration that carries GHIDRA_INSTALL_DIR or REA_JADX_MCP_CONFIG under its own env block therefore looked unconfigured: doctor answered not_configured while the server that client starts inherited the settings and worked. This is the recovery command the docs point agents at, so the false negative sent them back to re-apply fixes that were already in place. When the caller names exactly one client, read that registration's effective environment and hand it to the provider checks. Terminal variables that providers resolve outside server config (PATH, SYSTEMROOT) stay inherited, and running doctor without --client still reports this terminal. A registration the loader cannot read keeps its own registration check as the answer instead of being re-reported as four missing providers. Fixes #9102 * fix(doctor): keep setup's terminal settings and a failed close on the host Greptile found two regressions in the selected-client environment read. Provider probes now start from the terminal and overlay the selected registration, instead of replacing the terminal with the registration alone. `rea setup --client` passes its own client selection through the same doctor call, so on a first run with GHIDRA_INSTALL_DIR exported and no registration yet, the replacements made setup report providerConfigured: false and offer Hopper over the selected BYO provider. The registration still wins for every value it records. The registration read now runs inside the caller's resource scope and, when the close of the configuration file fails, retains the returned owner there so host.close() retries it. Dropping that owner left an unretired handle with no way to report the unfinished cleanup. * fix(doctor): leave a registration's expression settings unknown Greptile found the previous fallback filling a name the selected client records as a Cordis expression with the terminal's value. `dsh` keeps such a value as `!!js ...`, which is not a literal; the parser reports the name in `unresolvedSettings`, and merging the terminal into it then made probes certify a setting the client owns and this process cannot read. Unresolved names are now removed after the overlay, and an unreadable, malformed, or unresolvable registration returns no environment at all, so the caller keeps the terminal instead of a partly-known one. Provider checks report those settings as unconfigured, which is the honest answer for a chain that resolves outside REA. dsh's missing registration still inherits the terminal, which is the case `rea setup` depends on. * fix(doctor): fold registration settings by platform identity `selectedProviderSettings` overlaid a selected client's registration on the terminal with an object spread. On Windows a registration can record `ghidra_install_dir` while the terminal exports `GHIDRA_INSTALL_DIR`; the spread kept both spellings, and since provider checks read the canonical uppercase names, doctor either certified the terminal's install or reported the setting as unconfigured. An expression the registration marks unresolved was skipped under one spelling while its terminal value survived under the other. Merge the two layers through `mergeEnvironmentOverrides` and fold the result with `snapshotEnvironment`, so the registration's value wins regardless of how it spells the name and the provider sees the names it reads. Fold the unresolved names the same way before deleting them, and export the helper so the two platform identities can be covered directly. * style(doctor): wrap the long import in the runtime test oxfmt wants the three imported names on their own lines; the previous commit left the single-line form, which fails `npm run format:check`. * test(codebuddy): construct the registration command like its sibling clients `npxRegistrationCommand` was removed in c77735fa ("fix(setup)!: bind managed registrations to selected installation"). The CodeBuddy boundary test landed after that refactor and still imported it, so `npm run typecheck` failed on every branch that descends from merge fb841a95 — main included, where the main push CI is still queued. Use `currentClientRegistrationCommand()` the way the kimi, lmStudio and other client configuration tests already do. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> * fix(doctor): retain failed registration file cleanup * fix(doctor): preserve unknown client provider readiness * fix(doctor): scope Kuna readiness to its environment * test(doctor): respect Kuna host support * fix(doctor): read a registration's unresolved settings only where the probe needs them Every setting an expression made unresolved blocked readiness, even one the provider never consults for the configuration the client supplied. With a literal JAVA_HOME and jar path, JADX resolves Java by absolute path and does not read PATH, yet a dsh registration with an expression-backed PATH skipped the probe and reported the provider unknown. Ghidra is the same when both GHIDRA_INSTALL_DIR and JAVA_HOME are explicit. Decide per provider which unresolved setting the probe actually reads, and skip only those. Kuna's readiness list also omitted HOME and XDG_CACHE_HOME, which its cache root falls back to, so an unresolved cache input could let the probe check a fallback directory and report available without knowing the client's real cache. * fix(doctor): stop probing a registration expression as a literal Two findings from the review, both about handing a probe a value REA cannot interpret. REA_KUNA_CACHE_DIR made settingAffectsProbe ignore every unresolved Kuna setting, so an expression-backed REA_KUNA_COMMAND or REA_KUNA_JOBS silently fell back to a default and the provider could report ready. Limit the exception to HOME and XDG_CACHE_HOME, the two cache-location defaults. HOME and XDG_CACHE_HOME were also added to KUNA_DOCTOR_SETTINGS, which registrationEnvironment copies wholesale, so setup persisted ambient values a child already inherits. Split the readiness inputs from the settings setup writes. Qwen expands $VAR and ${VAR} in a recorded env value from the environment it runs with. REA cannot predict that, but it was handing the literal to the probes, so a registration appending to PATH made JADX search for a literal ${PATH} entry. Treat such values as unresolved for that client so the affected provider reports unknown instead of probing the literal text. * fix(registration): recognize a client's env expression at the shared reader Doctor decided which Qwen settings were expressions after the shared registration reader had already parsed them as literals, so doctor and setup/status held two interpretations of the same file. AGENTS.md requires normalizing once at the owning boundary, so move the recognition into ClientRegistrationEnvironment and let every consumer read the facts it returns. The reader now takes the client name, marks a variable-expanding client's $VAR and ${VAR} values as unresolved, and reports those names through unresolvedSettings. Doctor drops its own parser; setup and status pick up the same facts, which also keeps an expression-valued timeout out of the resolved budget instead of trusting the literal. * fix(doctor): preserve unresolved typed settings * style(cli): wrap the native data type path description The `inspect-native-data-type` argument description line is 82 columns, over the repository's 80-column `.oxfmtrc.json` limit, so `npm run format:check` fails on main and on every branch merged from it. It came in with #9465 and the following commits to this file did not touch it. Reformat the one call the formatter objects to; no behaviour change. --------- Co-authored-by: 2SinceJuly <202121119+2SinceJuly@users.noreply.github.com> Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>	2026-11-09 19:42:25 +08:00
Kaoru0822andClaude Opus 5.5	6a0ccf7eeb	fix(doctor): report provider settings a client registration does not record (#8645) ... * fix(doctor): report provider settings a client registration does not record Provider checks read the terminal running doctor, so a registration with no env block looked ready while its server reported not_configured. Compare what an available provider relied on with the registration's own file and report the setting names in a non-blocking registration_environment check. The client's effective environment stays unknown, so health and the exit status are unchanged. Fixes #8202 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> * test(doctor): write the Cordis fixture at its literal path The test resolved the path through supportedClients, whose default environment argument CodeQL traces to the fixture's writes even though the test passes {}. It only needed the path, so spell it like the other fixtures in this file and drop a leftover directory it never used. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>	2026-11-02 05:14:50 -08:00