morlutoandCursor Agent
5cbf06c7ad
* fix(ghidra): admit the 12.1 line and the install's JDK range The provider treated the verified Ghidra 12.1.4 build and JDK 21 as the only legal installation, so a working 12.1.x package or a newer JDK was rejected before analysis started. Admission now follows the 12.1 release line and application.java.min/max. A compatible build other than 12.1.4 keeps its observed version and records that the bridge was verified against 12.1.4. Fixes #821 * fix(ghidra): stop pinning the NativeAOT build to one version string The build script still rejected every Ghidra release except the literal 12.1.4 and every javac except major 21. It now accepts the 12.1 line and javac 21 or newer, compiles with --release 21, and records the observed Ghidra version. The JADX engine version uses the audited release constant. * fix(ghidra): report unverified builds on analysis results Session open uses health only as a startup gate and discards that execution, so the unverified-build limitation never reached CLI or MCP results. Attach it to every Ghidra execution for that install. --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com>
102 lines
5.4 KiB
Markdown
102 lines
5.4 KiB
Markdown
# REA roadmap
|
|
|
|
## Tool direction
|
|
|
|
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](https://github.com/morluto/rea/pull/555) removed REA permission grants,
|
|
scope ceilings, elicitation, and repeated approval fields.
|
|
[#572](https://github.com/morluto/rea/pull/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.
|
|
|
|
## Remaining evidence and provider work
|
|
|
|
The [platform roadmap](https://github.com/morluto/rea/issues/32),
|
|
[process and Hopper fidelity tracker](https://github.com/morluto/rea/issues/48),
|
|
and [browser tracker](https://github.com/morluto/rea/issues/39) track remaining
|
|
capabilities and proof. Their scope follows direct tools and agent-composed
|
|
experiments; custom replay languages and grant systems are not completion gates.
|
|
|
|
[Inline Evidence composition](https://github.com/morluto/rea/pull/585) now returns
|
|
the complete record accepted by comparison tools. Managed inspection uses an
|
|
explicit PE/CLI target independently of the native provider selection. Comparisons
|
|
preserve unknowns when observation is incomplete, and PTY diagnostics retain the
|
|
actual loader or startup failure. Browser cleanup reports incomplete teardown
|
|
alongside the primary failure; transient documents invalidate only the affected
|
|
frame's WebMCP registrations. Real-provider and platform claims still require
|
|
their corresponding verification lanes.
|
|
|
|
## Shipped behavior
|
|
|
|
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 configures Claude Code,
|
|
Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf, Devin, OpenCode, Antigravity,
|
|
GitHub Copilot CLI, Command Code, and VS Code using each client's configuration format.
|
|
|
|
Ghidra analysis supports Linux x64 and macOS x64/arm64 with Ghidra 12.1.x and the
|
|
64-bit full JDK that installation declares. Current 12.1 releases require JDK 21
|
|
or newer and set no maximum; the bridge is verified with Ghidra 12.1.4 and JDK 21.
|
|
macOS also requires the matching native decompiler. The
|
|
adapter exposes thirteen inventory operations and twelve function-analysis
|
|
operations, for 25 read-only operations total. Linux and macOS additionally support
|
|
atomic function-name and entry-comment edits with refreshed analysis; metadata
|
|
is discarded on close and executable bytes stay unchanged. 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](testing.md) for the prerequisites
|
|
and exact commands.
|
|
|
|
Experimental Windows x64 P0 now supplies bundled Job Object ownership,
|
|
protected runtime DACLs, and handle-based admission for native x86-64 PE
|
|
applications on local NTFS. Real ordinary-user CLI/MCP verification covers
|
|
all 25 read-only operations and cleanup. The [Windows P0 guide](windows-ghidra-p0.md)
|
|
describes this boundary and unverified broader coverage.
|
|
|
|
## 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.
|
|
|
|
Maintain Windows P0 with independent DACL readback, handle-based admission,
|
|
private authenticated IPC, and Job Object assignment before provider execution.
|
|
Process capture, Hopper, and broad filesystem-sensitive workflows remain
|
|
separate Windows projects; P0 does not imply their parity.
|
|
|
|
## Capability-selective setup
|
|
|
|
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.
|