rea/docs/roadmap.md

2.3 KiB

Installation roadmap

Shipped behavior

REA setup currently configures the capabilities that exist today: its bundled skill, detected agent integrations, optional Hopper provider, and validated bring-your-own Ghidra paths. It detects Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, and Devin. The first six have documented local MCP configuration boundaries and can be updated additively; Devin is reported but left unchanged.

The Ghidra foundation supports Linux x64 with exact Ghidra 12.1.2 and a 64-bit full JDK 21. Doctor validates those coordinates; approved setup propagates them to MCP registrations without installing or modifying either dependency. REA's packaged Java bridge then proves an isolated read-only headless import, post-analysis handshake, complete cleanup, ten admitted read-only inventory operations, and eight function-analysis operations. Real source-owned x86-64 debug/stripped ELF, AArch64 ELF, PE, and Mach-O fixtures cover program, procedure, string, symbol, external/thunk, memory, resolution, search, decompilation, assembly, calls, typed references, xrefs, and CFG semantics.

Ghidra maintenance boundary

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.

Capability-selective setup

After REA ships at least two real optional toolchains, setup can evolve into a capability-oriented wizard. 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.