REA provides inspection, capture, and comparison tools that return evidence directly. Agents choose commands, paths, browser actions, scripts, and local fixture servers, then compose experiments from those results. CLI and MCP must expose equivalent behavior and preserve observations, inferences, and unknowns.
#555 removed REA permission grants, scope ceilings, elicitation, and repeated approval fields. #572 removed the replay engines, Node characterization prepare/execute flow, and plan-only managed runtime correlation tool. Those systems are retired roadmap items. Existing evidence authority labels remain readable as provenance; they do not imply a current replay executor.
Local operations use the current user's OS permissions. Input and protocol validation, provider prerequisites, target identity, cancellation, and owned resource cleanup remain part of each tool's contract. Setup still discloses installation changes and requires approval before writing or installing.
The platform roadmap, process and Hopper fidelity tracker, and browser tracker track remaining capabilities and proof. Their scope follows direct tools and agent-composed experiments; custom replay languages and grant systems are not completion gates.
Current boundary work includes inline Evidence composition, CLI/MCP managed-tool and seed parity, partial-evidence comparison, and native PTY failure diagnostics. Removing replay does not resolve these defects. Real-provider and platform claims still require their corresponding verification lanes.
REA setup lets you select agent integration and optional Hopper installation. It installs the bundled workflow, configures detected agents, and can save verified paths for an existing Ghidra installation. It detects Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, and Devin. The first six can be configured; Devin is reported but left unchanged.
Ghidra analysis supports Linux x64 and macOS x64/arm64 with Ghidra 12.1.4 and a 64-bit full JDK 21. macOS also requires the matching native decompiler. The adapter exposes ten inventory operations and twelve function-analysis operations, for 22 read-only operations total. Approved setup saves verified installation paths in agent configurations without installing or changing Ghidra or Java.
Real-provider verification uses host-native debug and stripped fixtures plus a native type-layout object. A separate lane covers AArch64 ELF, PE, and Mach-O cross-target fixtures. See testing for the prerequisites and exact commands.
Windows Ghidra operations remain unavailable until REA implements verified Job Object process ownership, private runtime DACLs, and reparse-safe path admission. Windows package and adapter tests do not establish a usable real Ghidra session. The Windows P0 guide describes the intended boundary and remaining requirements.
Extend formats or semantics only with normalized provider-neutral contracts and real source-owned conformance. Hopper and Ghidra pseudocode or assembly text is not expected to match; unresolved targetless flow remains unknown. Automatic Ghidra acquisition, if ever added, remains a separately planned and approved related-tool change; setup must never install Java.
Before enabling Windows Ghidra operations, add current-user-only DACL creation and readback, handle-based reparse-point-safe path authority, a DACL-protected IPC backend, and Job Object assignment before provider execution. Process capture, Hopper, and broad filesystem-sensitive workflows remain separate Windows projects rather than implied parity.
Setup already lets users select agent integration and Hopper installation. Once REA supports installing additional analysis tools, it can expand these choices to match the work a user wants to do. It may ask whether the operator wants to investigate native binaries, websites, mobile applications, firmware, or runtime protocols, then propose only the tools needed for the selected work.
That future installer must preserve the current safety boundary:
- detect and reuse existing tools;
- disclose every source, destination, license, command, and system effect;
- prefer user-local installation;
- install only explicitly selected toolchains;
- require tool-specific authorization for unattended system changes;
- verify each installed tool before reporting readiness.
No placeholder tool choices or speculative installer registry are implemented until another supported toolchain makes the abstraction concrete.