Native directory decompilation verification — 2026-10-23¶

The completed analyst task is to export the bound provider's function inventory as one local pseudocode file per non-external function, with names, body ranges, provider/profile identity and the limitations of each used observation. The agent receives a manifest rather than the pseudocode. A function decompilation failure remains a recorded partial outcome and does not end the export.

Artifact, provider and correctness¶

The real target was the installed ELF x86-64 /usr/bin/sha256sum (60,368 bytes), SHA-256 6cd7c6bfc81d645ba13b927e31651a1466092a28ed0bd2632e82f8b27882b25e. It was read and analyzed statically, never executed. Both variants used the existing Ghidra 12.1.4 installation and JDK 21.0.12.1+1, Node 24.22.1, the locked npm dependencies, GHIDRA_HEADLESS_MAXMEM=1G and GHIDRA_HEADLESS_JAVA_OPTIONS=-XX:ActiveProcessorCount=2. The upstream analysis-profile digest was ae80ece8c83379eddabbdf379bbffca5da84c7df7fa7c159f45fa810468f85d9.

Baseline main was 5d2c8c2b78d2552da0e13a11d3e2678efb69810d. The feature branch integrates original PR head d3a207038cfc00d58a97b86b06af1368839bec99 on that base, with the maintenance changes described below. The frozen integration is c566cace04d24f8ccb3d54353ababf95b96c8830, including refreshed main bded9c628de23643aab81f98959b6a473318a240. The review fixes were verified on d3e0e96821a09a447785d100f3d85139b6e77e96. Each variant ran through the public production scripts/rea.mjs mcp entrypoint and the installed MCP SDK client.

The baseline called list_procedures, then procedure_info for each addressed entry and procedure_pseudo_code for each non-external entry. A local verifier used the returned Evidence to materialize the same function files and retain an index. It reused the feature's pure file-header renderer to keep file encoding equal; baseline analysis itself used only the existing public primitive tools. The existing batch_decompile item format does not retain per-function caveat associations; its workflow limitations aggregate across items. It would not provide equivalent per-function caveat provenance here, so the baseline uses primitive observations. The feature called decompile_all once per output directory. Both retained the complete MCP responses locally. A second export used a new output directory in the same session. The feature additionally resumed the verified warm export.

Both cold and warm exports examined the same 298 provider inventory entries: 236 written, 61 external, one failed. Addresses, statuses, body ranges, function names, pseudocode SHA-256 and complete emitted-file SHA-256 matched for every entry in both rounds. The target's bytes stayed unchanged. This proves export preservation of the provider's observed results; it does not establish that the provider found every actual function or that its pseudocode is original source.

Ghidra failed at 0x10a510 with Overlapping input varnodes; the failure code was execution_failure. The export still wrote 68 functions at later numeric addresses. Resume skipped every successful/external entry and retried the one failed entry without rewriting the successful files. Complete per-function caveats stayed in the index, and no pseudocode was returned in the manifest.

Measurements¶

The identical two-export task, including the full catalog discovery, open and close, used 3,723,191 → 981,913 estimated tokens (73.63% fewer). The extra verified-resume call is excluded from that comparison. The catalog itself grew from 969,665 to 974,049 estimated tokens. All 220 existing tool definitions were identical; only decompile_all was added. The per-export request/reply reduction is about 99.72%; applying that percentage to the entire task would overstate the benefit. A client which injects the entire catalog still pays its large fixed context cost.

The full verifier process family took 85.697 → 62.034 s elapsed, 111.166 → 68.185 s waited CPU, and 1779.4 → 1713.7 MiB sampled peak RSS. The after run additionally includes verified resume (0.266 s). These compare the retained baseline with the final review-fix run; no general CPU or elapsed-time speedup is claimed. Earlier maintenance trials ranged 50–83 s elapsed and 65–118 s CPU; they used earlier source revisions and are retained separately. Full-run figures include SDK, verifier formatting/hash checks and token estimation as well as REA and its provider. Per-phase sampled CPU was 70.19 → 43.16 s cold and 6.15 → 4.42 s warm, subject to delayed child accounting. The integration decision rests on equivalent results with far fewer agent-facing calls and estimated context, plus bounded auxiliary accumulators.

Cold/warm here describe primitive analysis reuse inside one provider session. Host filesystem caches were not flushed, and the baseline ran first. This is a paired functional measurement, not a statistical speedup claim. Provider startup and host load varied: the independent CLI runs below took longer than the MCP runs. No claim is made about cold OS caches or other binaries.

Token counts use tokenx 1.3.0 estimates of actual tool arguments and complete MCP call results, including both textual and structured projections. They are not model-specific BPE counts or actual model usage. The completed-task total also includes the actual tools/list response, open and close calls, and both exports. MCP handshake framing, orchestrator prompts, reasoning, subsequent agent reading of files and unknown model tokenizer costs are unmeasured.

Process-family RSS was sampled from /proc every 50 ms. Shared pages can be counted more than once, and short peaks can be missed. Full-run CPU uses waited child usage; per-phase CPU is a sampled /proc delta and can include delayed accounting of exited descendants. Limits were two CPU cores, a 2 GiB V8 heap per Node process, 1 GiB configured Java heap, 6 GiB sampled family RSS, 300 sampled family CPU seconds and 600 elapsed seconds. These are verifier controls, not a kernel memory limit. All reported completed runs exited zero without a resource stop. No reduction in Java's analysis memory is claimed.

The first baseline verifier attempt stopped at the real per-function Ghidra error because its harness initially required every primitive call to succeed. It took 74.325 s elapsed and 101.569 s waited CPU, with no resource stop. The completed baseline was corrected to retain that same failure and continue, matching the requested partial-result semantics. The failed trial is retained separately and is excluded from the paired completed-export table; no provider fix or disappearance of that failure is claimed.

Ownership, reuse and resource limits¶

The export owner parses a resumed journal once and updates its latest records only after append and sync complete. The shared function-record schema owns path/status validation for both journal and index; the append retains the parsed snapshot, including nested fields, rather than the caller's mutable input. Index generation consumes those committed facts instead of reading and parsing the whole journal again. Resume identity covers target SHA-256, provider identity/version, analysis-profile digest and layout. Unknown target/profile digests prevent resume. Files are checked afresh with the shared stable-file hash owner and bounded reads, rather than trusting an old checksum as current. decompile_all remains ineligible for snapshot replay: filesystem publication must run for the actual request.

Journal descriptors, verified staging areas and the directory lease have one cleanup owner. Failed close/removal retains that owner under the session; the lease is released after child cleanup and initialization cleanup finish. Initialization removes verified owned entries rather than recursively deleting unexpected files. Function path reservations use case-folded ASCII lookup keys while preserving the original address identity and chosen filename; collisions receive a stable address digest suffix. Resume refuses conflicting legacy reservations. These cases are exercised with the real filesystem on Linux; a real Windows/macOS filesystem was not exercised. A failed lease acquisition preserves even an empty directory and reports its created path, because another holder may be preparing it.

The inline failure accumulator retains at most 32 rows within 2,048 JSON-encoded UTF-8 bytes. It omits display names before omitting complete address/code/reason rows. Recent output-I/O diagnostics retain at most five rows within the same byte budget. The index retains all complete function records. Per-item caveat collection retains at most eight first-observed provider/text groups within an 8,000-byte JSON-encoded UTF-8 text budget, instead of retaining all distinct caveats to rank them. Omitted observations are counted without retaining their text; this count is not a distinct-caveat count. Complete caveats remain in the owning index.

Inventory and latest journal/index state still scale with the number of functions and their retained metadata. Larger exports, long-running journal histories and worst-case metadata expansion were not capacity-benchmarked; this report makes no 100,000-function memory guarantee. The attempt limit is a positive safe integer and does not allocate according to its numeric value.

Validation¶

npm run check passed after the review fixes on d3e0e9682: type checking, lint, formatting, dependency/metadata checks, module boundaries and architecture guards. npm run docs:check also passed, including nine README conformance cases. After the main refresh, 226 tests passed across ten files, including the four Ghidra profile suites and the six CLI/MCP/workflow/schema files. Earlier Hopper lease and session-cleanup coverage below is additional; repeated tests are not counted as new cases.

• The focused integration run passed 112 tests across 11 files; four macOS-specific real-Hopper startup cases were skipped on Linux. It includes public CLI/MCP behavior, actual SDK schema conversion/dialect/client checks, the shared lease extraction, session cleanup retry and descriptor ownership.
• After the final caveat/cleanup changes, 75 tests passed across the four affected files: 48 export cases, 20 workflow-Evidence cases, six filesystem ownership cases and one MCP caveat case. This adds five distinct cases to the earlier integration coverage; overlapping executions are not summed.
• Follow-up review coverage passed 72 tests across the workflow and MCP files, plus 22 filesystem/CLI/schema cases. This includes portable filename reservations, conflicting legacy journals, encoded caveat budgets and long failure names. Against the published pre-fix implementation, all three new regression cases failed; the complete SDK result for the long-name case was 485,937 bytes, above the 51,200-byte tool window. The repaired case retains useful failures inline and verifies complete names and caveats in the index.
• Original-PR controls reproduce the uppercase-input refusal, valid-journal initialization cleanup race, lost failed-close ownership, unexpected-file deletion, and the empty-root lease-acquisition race. These controls use the original production implementation, not the repaired one. An additional production selection control returns zero matching aliases before the fix and the selected alias after it. A separate negative control of the maintenance index-reuse change reproduced journal/index disagreement after mutation of the append input; retaining the parsed snapshot resolves it.
• Three real Ghidra CLI calls passed: uppercase address range plus limit 1 wrote one of two functions; resume with limit 100001 skipped the verified file and wrote the other; an unmatched name selected zero and reported 298 excluded inventory entries. Both output files matched the full MCP export. The CLI group took 166.128 s elapsed, 120.848 s waited CPU and 1257.0 MiB sampled peak family RSS, without a resource stop.

Raw measurements and verifier scripts remain in the maintainer workspace at /tmp/rea-maintenance-20261023/6170/, including completed and failed attempts, full MCP exchanges, all function outputs and equivalence checks. They are local verification artifacts, not shipped provider projects or committed binaries. Real-provider coverage here is Linux x86-64 Ghidra only. Hopper, IDA, Windows and macOS were not exercised with real providers by this verification.

CI attribution¶

The first maintenance CI run used synthetic merge 798091d99f5c9f434d832981e0c8d28a5ec4aabc and exact base 9fd78a74f84a8e924bd58e7deaf5934bfb24f53c. All 54 observed failing assertions reproduced on both revisions with identical failure diagnostics after normalizing only their checkout paths: 11 source cases and 43 built cases. Forty built failures came from cancelled-shard logs and were absent from the aggregate report; cancelled coverage is not claimed as executed.

The real-browser job also failed its stable-capture checkpoint. A bounded checkpoint-only execution of the production verifier reproduced the same dom_structure: unchanged, scripts: unknown result on exact base and merge, with cleanup retained. Local Chromium was 155.0.8059.79 on Debian 12; the CI Chrome version was not measured. This does not establish a passing complete browser workflow. The public CI attribution records the controls and separates these baseline failures from the three actionable feature review findings fixed above.