[GH-ISSUE #8067] [Bug] verify-real-hopper asserts complete relationship coverage that the Hopper provider always reports as unknown #4664

New issue

Open

opened 2026-10-31 00:52:11 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:52:11 +00:00

Owner

Originally created by @Eldergenix on GitHub (Oct 29, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8067

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

scripts/verify-real-hopper.mjs fails on macOS with a real Hopper installation because its semantic fixture check asserts complete relationship coverage for analyze_function, while the Hopper provider deliberately reports that coverage as unknown.

The verifier asserts (scripts/lib/real-hopper-semantic.mjs):

assert.deepEqual(reply.structuredContent.relationship_coverage, {
  status: "complete",
});

The provider unconditionally returns unknown for procedure_callers, procedure_callees and analyze_function (src/hopper/HopperProvider.ts), with the reason "Hopper reports caller and callee procedures through independent public API inventories. Their completeness … has not been established." The source review on #5438 describes this as the intended change.

Both lines are unchanged on main today, so the lane cannot pass on any host while the provider keeps this declaration.

Reproduction

Check out rea-agents-6.8.0, npm ci --ignore-scripts, npm run build:cached.
Install Hopper (here via rea setup --install-hopper, demo mode) and export HOPPER_LAUNCHER_PATH.
npm run verify:fixtures && node scripts/verify-real-hopper.mjs

Expected behavior

The verifier's coverage expectation matches the provider's declared contract: either assert the unknown status with limited_directions: ["callers", "callees"] and the documented reason, or check coverage per facet. Alternatively, the provider would have to return complete again where it can prove it.

Impact and scope

Only the real-provider verification lane is affected. Ordinary Hopper analysis works: rea decompile <target> <procedure> --provider hopper returns correct pseudocode on the same host. Anyone running verify:hopper to validate an installation gets a failure that does not point to a setup problem.

REA version

rea-agents 6.8.0 (tag rea-agents-6.8.0, 160d821). The same assertion and provider code are present on main at 940d71a.

Runtime and platform

macOS 26.6 (25G5065a), Apple Silicon arm64, Node.js 24.22.2, Hopper Disassembler 6.6.0 (demo mode, installed by rea setup --install-hopper).

Target and artifact context

REA's own fixtures generated by npm run verify:fixtures; no third-party target.

Interface

MCP

Earliest failure stage

Transport or result projection

Relevant output or evidence

AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal:
  actual: {
    status: 'unknown',
    reason: 'Hopper reports caller and callee procedures through independent public API inventories. Their completeness, including resolved tail calls and agreement between reverse and forward relationships, has not been established. Observed relationships are retained.',
    limited_directions: [ 'callers', 'callees' ]
  },
  expected: { status: 'complete' },
    at analyzeFixtureProcedure (scripts/lib/real-hopper-semantic.mjs:327:10)
    at async verifyRealHopperFixture (scripts/lib/real-hopper-semantic.mjs:130:5)
    at async scripts/verify-real-hopper.mjs:378:27

Typed outcome or recovery expected

The verifier accepts the provider's typed unknown relationship coverage (with its limited directions and reason) instead of failing.

Analysis or suspected cause

The provider's coverage declaration was changed (see the source review on #5438) without updating real-hopper-semantic.mjs, which still encodes the earlier complete contract.

Additional context

On the same host, verify-real-ghidra.mjs and verify-real-ida.mjs (native IDA Free profile) pass, so the verifier harness itself runs correctly here.

Originally created by @Eldergenix on GitHub (Oct 29, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8067 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior `scripts/verify-real-hopper.mjs` fails on macOS with a real Hopper installation because its semantic fixture check asserts complete relationship coverage for `analyze_function`, while the Hopper provider deliberately reports that coverage as `unknown`. The verifier asserts ([`scripts/lib/real-hopper-semantic.mjs`](https://github.com/morluto/rea/blob/rea-agents-6.8.0/scripts/lib/real-hopper-semantic.mjs#L327-L329)): ```js assert.deepEqual(reply.structuredContent.relationship_coverage, { status: "complete", }); ``` The provider unconditionally returns `unknown` for `procedure_callers`, `procedure_callees` and `analyze_function` ([`src/hopper/HopperProvider.ts`](https://github.com/morluto/rea/blob/rea-agents-6.8.0/src/hopper/HopperProvider.ts#L357-L369)), with the reason "Hopper reports caller and callee procedures through independent public API inventories. Their completeness … has not been established." The source review on #5438 describes this as the intended change. Both lines are unchanged on `main` today, so the lane cannot pass on any host while the provider keeps this declaration. ### Reproduction 1. Check out `rea-agents-6.8.0`, `npm ci --ignore-scripts`, `npm run build:cached`. 2. Install Hopper (here via `rea setup --install-hopper`, demo mode) and export `HOPPER_LAUNCHER_PATH`. 3. `npm run verify:fixtures && node scripts/verify-real-hopper.mjs` ### Expected behavior The verifier's coverage expectation matches the provider's declared contract: either assert the `unknown` status with `limited_directions: ["callers", "callees"]` and the documented reason, or check coverage per facet. Alternatively, the provider would have to return `complete` again where it can prove it. ### Impact and scope Only the real-provider verification lane is affected. Ordinary Hopper analysis works: `rea decompile <target> <procedure> --provider hopper` returns correct pseudocode on the same host. Anyone running `verify:hopper` to validate an installation gets a failure that does not point to a setup problem. ### REA version `rea-agents` 6.8.0 (tag `rea-agents-6.8.0`, 160d821). The same assertion and provider code are present on `main` at 940d71a. ### Runtime and platform macOS 26.6 (25G5065a), Apple Silicon arm64, Node.js 24.22.2, Hopper Disassembler 6.6.0 (demo mode, installed by `rea setup --install-hopper`). ### Target and artifact context REA's own fixtures generated by `npm run verify:fixtures`; no third-party target. ### Interface MCP ### Earliest failure stage Transport or result projection ### Relevant output or evidence ``` AssertionError [ERR_ASSERTION]: Expected values to be strictly deep-equal: actual: { status: 'unknown', reason: 'Hopper reports caller and callee procedures through independent public API inventories. Their completeness, including resolved tail calls and agreement between reverse and forward relationships, has not been established. Observed relationships are retained.', limited_directions: [ 'callers', 'callees' ] }, expected: { status: 'complete' }, at analyzeFixtureProcedure (scripts/lib/real-hopper-semantic.mjs:327:10) at async verifyRealHopperFixture (scripts/lib/real-hopper-semantic.mjs:130:5) at async scripts/verify-real-hopper.mjs:378:27 ``` ### Typed outcome or recovery expected The verifier accepts the provider's typed `unknown` relationship coverage (with its limited directions and reason) instead of failing. ### Analysis or suspected cause The provider's coverage declaration was changed (see the source review on #5438) without updating `real-hopper-semantic.mjs`, which still encodes the earlier `complete` contract. ### Additional context On the same host, `verify-real-ghidra.mjs` and `verify-real-ida.mjs` (native IDA Free profile) pass, so the verifier harness itself runs correctly here.

bsakaguchi referenced this issue

2026-10-31 01:13:46 +00:00

[PR #4664] [CLOSED] fix(mcp): keep bounded process capture guidance preparatory #6350

bsakaguchi referenced this issue

2026-11-01 21:12:26 +00:00

[GH-ISSUE #8398] [Design] Give capture_process_scenario a prepare-only mode so the preparation prompt can suggest a non-executing call #6585