mirror of
https://github.com/morluto/rea.git
synced 2026-11-09 16:26:36 +00:00
7baed55130
* 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 inc77735fa("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 mergefb841a95— 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>
Documentation directory
REA documentation is organized by reader task and document owner. This directory
links every authored guide; the site also serves separate
product pages. The VitePress documentation source is this docs/ tree.
Getting started
- Installation and setup
- Client configuration and troubleshooting
- CLI and Evidence
- Guided MCP prompts and completion
Native binaries
- Native binary investigation
- Go binary build metadata
- Offline binary diagnostics
- Recorded crash evidence
JavaScript and Electron
- JavaScript Application Graph
- Cross-layer JavaScript application workflows
- JavaScript artifact reconstruction
- JavaScript source recovery
- Passive Node and Electron runtime observation
- JavaScript static/runtime reconciliation
- Electron file-page observation
Browser and captured websites
- Website observation with CDP
- Browser scenario contract
- Website runtime source attribution
- Historical web network captures
- HTTP/3 capture lab
- Captured website source locations
- Captured website module relationships
- Captured website scripts and static JavaScript analysis
Android applications
- Static Android APK analysis
- Apktool resource decoding
- ADB device inspection and acquisition
- Flutter build identification
Apple applications
.NET assemblies
Firmware
HarmonyOS packages
WebAssembly
EVM contracts
Databases and recorded packets
Process capture and instrumentation
Signal recordings
Provider setup and formats
- Ghidra provider semantics
- DOS MZ and COM analysis with Ghidra
- Optional NativeAOT metadata recovery
- MIPS ELF analysis through Ghidra
- PSP static ELF analysis through Ghidra
- RISC-V ELF analysis through Ghidra
- Windows Ghidra P0
- Headerless raw-binary analysis with Ghidra
- IDA provider
- JEB instrumentation and analysis
Contracts and evidence
Development and verification
- Settings and recovery
- MCP tool design
- Testing REA
- Client and agent verification
- Reconstruction readiness conformance
- Releasing REA
- REA roadmap
Release migrations
Architecture and authoring
- Architecture map
- Documentation ownership and contribution model
- Feature specifications
- Architectural decision records
Machine-owned documentation
| Path | Owner and update command |
|---|---|
public/product-catalog.json |
Ignored contract projection; npm run docs:generate |
verification/managed-conformance-*.json |
Ignored managed conformance projections; npm run evidence:generate |
error-contract.schema.json |
Tracked schema from contracts; npm run docs:error-schema |
user-visible-errors.csv |
Authored error classification inventory; preserve its schema |
releases/<version>.contributions.json |
Durable release contribution record; follow the release guide |
assets/ |
Shared authored images referenced by guides |
Do not edit generated catalogs or evidence to change product facts. Change their canonical contracts or producer and regenerate. Historical release records retain the exact commit messages and references from the release they describe.
Additional guides
- Offline API contract inventory
- Bun standalone executables
- Capability composition and ownership
- .NET single-file bundles
- ESP flash images
- U-Boot FIT images
- Measure MCP catalog costs in Codex
- Offline Playwright traces
- Testing lanes and provider verification
- UF2 and DfuSe images
- WeChat mini-program wxapkg archives
- Binary hardening
- Desktop application capture
- Desktop application export
- Desktop application state
- Desktop application tasks
- Desktop build computer
- Desktop build witness
- iNES containers
- Build RL environments with REA
- Agent environments from recorded captures
- APK signature schemes
- Apple IPS crash reports
- Static analysis in GitHub Actions
- Desktop installation directories
- Flattened devicetree inspection
- Electron fuse state
- ELF note tables
- Erlang BEAM files
- ESP images
- GameCube DOL analysis through Ghidra
- PowerPC ELF analysis through Ghidra
- Godot PCK archives
- Static CUDA and HIP code objects
- Intel HEX and S-record images
- IL2CPP metadata
- Static JavaScript route inventory
- Linux kernel modules
- Kuna provider
- Model file declarations
- Match native functions across builds
- Node.js single executable applications
- PE Authenticode certificate tables
- PE import and delay-load tables
- PE TLS callbacks and load configuration
- Python packaged applications
- CPython pyc inspection
- Reconstruction coverage
- Reverse-engineering tool integrations
- Rust binary dependency metadata
- U-Boot legacy uImage containers
- UnityFS AssetBundle archives