* fix(cli)!: retain repeated WASM input paths
BREAKING CHANGE: caller_input_paths values may now be ordered arrays of strings as well as strings. Clients must accept both forms.
* fix(capture): retain safe caller path selections
* fix(evidence): retain auxiliary selections in direct summaries
* test(wasm): separate SDK schema and acquired-input coverage
* fix(electron): model view constructors as window-like surfaces
Electron's static pass recognized a window only through the literal
`BrowserWindow` constructor, so `BaseWindow`, `BrowserView` and
`WebContentsView` produced no node and their literal `webPreferences` were
invisible. IPC registrations reached through such a view's own
`webContents.ipc` were dropped too, because the receiver resolver had the
same single-constructor gate -- VS Code alone registers seven channels this
way, and a shipped sample of four applications put 29 percent of window
construction sites on an unmodeled constructor.
Read webPreferences through one constructor set shared by the construction
inspector and the IPC receiver resolver. The finding only carries the new
`window_constructor` field when the site is not `BrowserWindow`, so existing
projections and their evidence stay byte-identical. A non-BrowserWindow
owner is not admitted for `loadFile`/`loadURL` on itself: only BrowserWindow
exposes those directly.
* fix(electron): keep the view constructor label lookup nullable
Observation labels are nullable in the application graph schema, so the
byLabel lookup failed tsc with TS18047 and took the Static checks job
down with it.
---------
Co-authored-by: 2SinceJuly <202121119+2SinceJuly@users.noreply.github.com>
Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>
* fix(javascript): keep export bindings out of module views
Exported symbol bindings reuse the javascript-module node kind, so the modules collection counted one row per export alongside the owning module. On a CommonJS or ESM file with N exports, inspect_analysis_view reported N+1 module units, module pages listed indistinguishable rows sharing the module path, and item selection by selector.path failed with "Multiple modules have path".
Treat a node whose observations carry semantic_role export-binding as an export of its owning module, not a module unit, and exclude it from module entries. Export bindings remain distinct graph entities for export-shape comparison and version matching.
Validation: a domain regression in analysisView.test.ts and a CLI acceptance regression over a real CommonJS analysis both fail on main and pass with this change. Also ran the analysis view, MCP boundary, CLI boundary and JavaScript acceptance suites (125 tests), npm run check:fast, and the MCP catalog schema test after regenerating .cache/mcp-tool-catalog.json.
* test(javascript): run the export-binding view case on the shared CLI
The case starts a compiled CLI process for each of its three commands,
paying startup and tool registration three times per run. The fixture
already provides a file-scoped process for calls with no stdin or explicit
timeout, so use it.
* style(javascript): format the constructed-evidence type in the module-view case
The acceptance case's inline graph type did not match what oxfmt emits for the
80-column limit, so `format:check` refused the tree. Reflow only; the assertions
are unchanged.
* 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: morluto <76467478+morluto@users.noreply.github.com>
* fix(elf): qualify Linux CORE notes by the declared ABI
* test(mcp): cover source fitting and omitted delivery budgets
---------
Co-authored-by: hhang <169027046+xu91102@users.noreply.github.com>
* 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>
* fix(javascript): analyze first-party sources before dependencies
Every source in one application analysis charges the same parent result
budget, and sources were offered in lexical inventory order. On an Electron
app.asar, node_modules/ sorts before an electron-vite out-*/ directory, so
dependency files spent the budget and every first-party main, preload, and
renderer file had its semantic analysis not started and its application
projection rejected. The summary then reported zero windows, preloads, and
bridges while electron_semantics still said "recovered".
Offer application JavaScript before JavaScript under node_modules; reported
files keep inventory order. Count Electron boundary facts only from files
whose projection was admitted, and report electron_semantics "partial" (with
a limitation naming the count) when an Electron-loading source was not fully
examined or reported.
Fixes#9321
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* fix(javascript): treat limited Electron examination as partial coverage
A static pass can stop early at the Electron wrapper expansion budget or
another resource limit without failing the worker. Such a source carries no
analysis or projection failure, so its retained IPC or bridge facts still
reported electron_semantics "recovered". Read the owned examination status
and count a limited Electron-loading source as incomplete.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>
* feat(providers): canonicalize selection diagnostics
Extend candidate statuses with selection source and stable rejections derived from readiness and target support. Automatic selection now keeps every rejected candidate attributable, while explicit and ambiguous outcomes remain fail-closed and deterministic.
* test(providers): surface typed selection errors
Follow the repository test guide: throw the typed Result error before
reading the selected value so a failure reports the provider error.
* fix(javascript): mark unisolated program-var route values unproven
`JavaScriptRouteScan.#resolve` now records the identifier whenever a value
proof depends on a program-scope `var` in a script without a proven isolated
runtime. That binding is a global-object property, so `globalThis.NAME` or an
alias can replace it after the source initializer.
The mark lives in the shared resolver, so every consumer degrades from one
fact instead of each one opting in:
- path segments and navigation destinations stop asserting the source value
and report an unknown interpretation;
- an index flag stays unproven, as before;
- a route container keeps its source route set and reports an incomplete
interpretation, so `var routes=[...]` no longer loses every route.
The source initializer is still followed, which is what lets a container
consumer keep its facts while disclosing the gap.
* fix(javascript): keep literal child routes behind an unisolated children array
Rejecting the whole children configuration marked its records as claimed
by the interpretation, so the automatic-root loop skipped them and the
literal child paths disappeared even though their absolute paths need no
parent proof. Keep the source records reachable and let the walker report
the unproven ancestry as an interpretation gap.
* test(javascript): bound the index-route CLI acceptance matrix
The flag matrix runs sixteen CLI invocations in one test and passed at 20.7 s
against a 30 s default timeout, so it timed out on a loaded runner. The same
matrix is already asserted per case in javascriptRouteScan.test.ts, where each
case is an in-process parse; this file keeps one resolved case and one
unresolved case to prove both branches of the public CLI view.
* fix(javascript): retain ownership of unproven route literals
Keep source ownership separate from runtime value proof so rejected program-var route segments cannot reappear through the generic constant pass. Cover path, route, typed and alias forms, retain navigation controls and independent literals, and verify inventory and public CLI projections.
Run the existing CLI index cases independently so repeated process startup does not consume one combined test deadline. Preserve both cases and all assertions.
* fix(javascript): keep unisolated navigation data out of route literals
An unisolated program-var slot holds data, not a route. Refusing its
runtime identity released the object back to the independent route scan,
which then reported a query payload as a nested route. Report the object
as consumed navigation data and stop following it as a path.
* fix(javascript): follow rejected navigation data without trusting it
Claiming the whole object for a rejected value also claimed its sibling
properties, so an independent route in the same object disappeared.
Keep the property selection: ownership follows the slot, and only the
route consumers refuse an unproven runtime identity.
* fix(validation): stop reporting an exclusive bound as an inclusive minimum
Input issues report minimum and maximum as inclusive bounds, as JSON Schema does, but the projection ignored Zod's inclusive flag. A .positive() field such as inspect_analysis_view view.limit or observe_native_ui pid rejected 0 and reported minimum: 0, naming the rejected value as allowed; .lt() limits had the same problem for maximum. An exclusive bound now keeps the schema's own message (for example 'expected number to be >0') instead of a false inclusive bound. Inclusive bounds are unchanged.
* test(validation): cover exclusive and inclusive bounds through MCP
* fix(cli): advertise the source-location path and URL constraints
trace-web-source-location declared manifestPath, sourceMapPath and sourceMapUrl
as bare strings, so `--schema --json` advertised them with no minLength and no
absolute-path pattern. The service then refused a relative manifest or map with
a post-parse invalid_request naming manifest_path and source_map.path, while
trace-web-module-imports already advertises those constraints from its domain
fields.
Bind the three positionals to webSourceLocationInputSchema so the domain field
owns the bounds, format and help, matching the rule in cliDecimalField that the
domain field owns bounds, defaults, nullability and help. The CLI now refuses a
relative or NUL-bearing value at its own boundary with a field-level message
instead of surfacing a service-level failure.
Add a boundary test that compiles the advertised args schema and asserts the
shared path and non-empty URL constraints, next to the existing sibling case.
* test(cli): isolate the NUL rejection from the absolute-path check
The boundary case for trace-web-source-location used "manifest\0.json", which is
also a relative path. The absolute-path constraint alone rejects it, so the case
would still pass if schema conversion dropped the NUL pattern. Use an absolute
path with an embedded NUL instead, and add the same case for sourceMapPath.
* style(test): wrap input schema assertions for oxfmt
The two unknown-byte cases exceeded the line width and tripped
format:check in CI. No assertion changes.
* fix(cli): admit native data type selectors before opening a target
* fix(cli): advertise the native data type selector choice
* test(cli): reject invalid native data type selectors before target access
* test(cli): cover native data type selector discovery
* fix(cli): reject an empty native data type target before resolution
inspect-native-data-type still declared its positional target as a plain
string after #7956 moved its sibling local-file commands to
localPathStringSchema, so an empty target passed validation and resolved
to the working directory. Use the shared schema and cover the command in
the empty-target admission table.
* refactor(cli): share native data type selector guidance owner
* test(cli): bind native data type selector checks to owning contracts
* fix(wasm): admit compatible 1.0.x WABT releases
REA_WABT_BIN_DIRECTORY admission compared each --version banner to the
literal 1.0.42, so a Homebrew or rolling-distribution WABT that advanced
past that build was refused even though wasm-validate, wasm-objdump and
wasm2wat accept the same flags and emit the same output shape. Callers had
to keep a hand-extracted 1.0.42 tarball alongside the system package.
Admission now accepts the release range ^1.0.42 and records the observed
banner, matching how the Wakaru adapter already admits compatible builds.
The verified release stays the reference: a banner other than 1.0.42 is
retained as tool_profile.release and provider.version and the report states
that only 1.0.42 was verified. All three tools must report the same release,
since one directory is one installation. Managed downloads stay pinned.
Fixes#9197
* fix(wasm): bound WABT admission to releases the report schema accepts
WABT_ACCEPTED_RANGE was "^1.0.42", which also admits 1.1.0 and later 1.x
releases, while wasmArtifactSchema only accepts 1.0.x banners. A configured
tool reporting 1.1.0 therefore passed version admission, ran the inspection,
and then failed at report parsing. Use the explicit ">=1.0.42 <1.1.0"
range so admission and the schema agree, and test the boundary.
Also carry the compatible-release warning into both partial-Evidence
builders. Previously only successful reports stated that REA verified
1.0.42, so a validation rejection or later read failure under a
compatible release silently dropped the uncertainty that a success reports.
Share the text through wabtReleaseLimitation so both paths stay aligned.
* fix(wasm): stop claiming the 1.0.42 commit for a newer admitted release
A caller-supplied 1.0.43 or 1.0.44 was admitted with the observed banner in
tool_profile.release, but source_commit still carried the 1.0.42 revision,
which is a claim about a build that did not run. Emit null for any release
other than the verified 1.0.42; the observed release and each executable
digest still identify what actually ran.
Also spell the accepted range as it is defined (>=1.0.42 <1.1.0) in the guide
and the failure fixture instead of ^1.0.42, which in semver admits 1.1.0.
---------
Co-authored-by: 2SinceJuly <202121119+2SinceJuly@users.noreply.github.com>
* fix(objdump): reflect observed launch failure in discovery availability
Distinguish a statically registered standalone command from an executable
whose launch has failed in the active server session. Discovery leaves
unprobed commands optimistically available, reports an observed launch
failure as provider_unavailable with the command remediation, keeps the
tool callable for retries, and clears the failure after a subsequent
successful launch.
Fixes#8826.
* test(reverse): verify overlapping command launch dispatch ordering
* test(reverse): unblock gated test workers before awaiting service closure
* test(reverse): bound lifecycle acknowledgement and join launched workers
* fix(reverse): distinguish host capacity exhaustion from command launch failures
* fix(reverse): preserve host capacity across Linux process ownership preparation
* fix(reverse): exclude process ownership admission failures from command launch state
* fix(reverse): preserve Darwin process ownership preparation error across command launch
* fix(reverse): disambiguate cleanup declaration in provider observation
* fix(reverse): preserve command deadline timeout during Darwin ownership preparation
* fix(reverse): isolate Darwin baseline ps errors and provide platform-aware admission guidance
* fix(reverse): rely on typed baseline admission failures and use owning repair formatter in tests
* test(reverse): use owning formatters for process ownership remediation assertions
* fix(reverse): restrict Linux ownership prerequisite remediation to missing ps and preserve system error codes
* fix(reverse): retain typed process ownership prerequisite with preserved error codes
* fix(reverse): remove unvalidated error label fallbacks and keep admission tags out of system_code
* fix(reverse): keep Windows native runner failures out of command-launch state
* fix(process): preserve current_process_unreported refusal in Linux provider readiness
* fix(process): distinguish no-code ps failure from missing ps and cover rizin launch failure
* fix(windows): classify process_spawn host-control rejections as RuntimeControlUnavailableError
* fix(desktop): keep a failed library owner query unknown
dpkg-query -S exits 1 when some requested path has no owner and 2 when
it could not answer at all. LibraryPackageInventory.packageOwners only
rejected the missing and failed outcomes, so an exit of 2 with empty
stdout parsed as a successful empty owner map and every located library
was recorded in unpackaged_libraries. That turns a failed lookup into an
incorrect ownership fact and drops the reason, while the executable
owner lookup in DebianPackageInventory already treats exit codes above 1
as unknown.
Treat an exit code above 1 as a failed query for the batch, report it in
library_packages_reason, and leave the libraries it covered out of
unpackaged_libraries. Already established missing_libraries are kept.
* fix(desktop): retain completed library ownership queries
* fix(desktop): report ownership gaps per library
---------
Co-authored-by: 2SinceJuly <202121119+2SinceJuly@users.noreply.github.com>
Co-authored-by: morluto <76467478+morluto@users.noreply.github.com>
morluto