Docs read 2026-10-17 · measurement 2026-10-14

hexvero and REA for Electron release review

Use REA to understand how someone else's app works, down to decompiled functions and run-time traffic. Use hexvero to review what your own release changed, with the line in both builds, and to gate that release in CI. Many teams will want both.

Choose by the question

• "How does this feature work, and can my agent rebuild it?" REA: static analysis, Hopper, Ghidra or IDA, runtime capture of browsers, processes and Android devices, firmware, signed evidence records.
• "What did this update change in IPC, preload, windows and hosts, and may it ship?" hexvero: a two-build diff per list, the preload → channel → handler map, a JSON policy with baseline and suppressions, SARIF, a local review UI and an offline report.

What they share

Both are MIT, both read Electron apps statically, both trace IPC and the preload bridge, and both compare two versions: REA documents compare_application_versions with unknowns on partial coverage. hexvero is an independent implementation with no REA code.

What only one of them does

• REA, not hexvero: decompiler integrations, runtime capture, device and firmware work, hash-addressed evidence, sender-validation observations in IPC handlers.
• hexvero, not REA (not found in REA's docs): a release policy with exit codes, baseline and suppressions; SARIF output; a single-build audit of Electron's security checklist items.

One dated measurement

On corpus/holdout2, two Electron apps in three builds each, written by an agent without access to either tool, hexvero before its tuning round and REA 6.5.0, run 2026-10-14. Hit of expected, false in brackets:

One set, one day, REA as published then; REA has released since. Every command and checksum: rea-scorecard.md. Read it as a description of two tools on one input, not a ranking.

Try hexvero on the example

$ npx hexvero demo
$ npx hexvero ui --demo --open