morluto
ed933d1893
* feat(native): add UI and dispatch investigation workflows * feat(ghidra): support macOS host validation * docs: update native investigation capabilities * feat(artifacts): decode compiled Interface Builder archives * feat(ghidra): expose bounded p-code value flow * test(ghidra): split host and cross-format verification * fix(verify): follow complete result contracts * refactor: remove unused authorization and schema helpers * refactor: remove unused evidence result alias * fix(ghidra): report jump-table evidence precisely * fix(verify): align browser scenario fixture schema * fix(setup): compare parsed client config structurally * test(ghidra): verify AArch64 jump-table mappings * fix(ghidra): recover AArch64 byte jump tables * test(artifacts): verify compiled interface builder archives * feat(native): trace UI actions through handlers * fix(tests): update native trace and shutdown fixtures * fix(verification): diagnose browser scenario failures * fix(browser): wrap scenario snapshots in capture state * fix(native): bind and bound investigation workflows * fix(artifacts): preserve bounded interface builder evidence * fix(ghidra): enforce admitted hosts and preflight tools * fix(native): preserve trace cancellation and bounds * test(application): expect bound analysis target evidence * fix(native): preserve investigation bounds and cancellation * fix(application): preserve bundle and unresolved trace evidence * style(test): format artifact subject fixture
3.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.4 and a 64-bit full JDK 21. macOS is not an admitted Ghidra host. An experimental Windows x64 P0 admits approved native x86-64 PE applications through the same 19-operation Java bridge. Doctor validates those coordinates; approved Linux 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 nine 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. Function dossiers also expose bounded Ghidra high-p-code def-use and memory or control-flow effects, mark decompiler-dead operations, and report truncation plus known omitted counts. This is intra-function decompiler evidence; cross-function state flow remains unimplemented. Hosted Windows CI covers build, package, target admission, transport, and lifecycle seams; a controlled self-hosted workflow covers the real Ghidra P0 claim.
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.
Before Windows advances beyond P0, 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, controlled replay, Hopper, and broad filesystem-sensitive workflows remain separate Windows projects rather than implied parity.
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.