48 lines
2.3 KiB
Markdown
48 lines
2.3 KiB
Markdown
# 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.
|