morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 07:47:29 +00:00

[GH-ISSUE #8478] [Bug] Kuna ambiguous procedure names suggest schema repair #6622

New issue

Open

opened 2026-11-01 21:12:45 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

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

Owner

Originally created by @morluto on GitHub (Nov 1, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8478

Before submitting

I searched open and closed issues and pull requests for related reports.
I removed credentials, private paths, and sensitive target data.

Area

Native analysis or decompilation

Observed behavior

With a valid but ambiguous Kuna procedure name, REA's error message lists both candidate addresses and asks the caller to select one. Its structured recovery simultaneously says to inspect the input schema and correct the fields. The input conforms to the schema; schema inspection does not choose a function.

Reproduction

On REA main a6caa79bf4f393c02601fbf2f6df246eae0b1558, Node 24.22.1, macOS arm64 and Kuna 1.986, open a source-owned arm64 Mach-O containing two C++ overloads named audit_over.

Call procedure_address, procedure_assembly, procedure_callers, or analyze_function with { "procedure": "audit_over" }. Each returns invalid_request, message audit_over names 2 Kuna entries (0x1000003f8, 0x100000408); select one by address., and recovery.kind: inspect_input_contract. Calling the same operation with procedure: "0x1000003f8" succeeds in the same session; addresses are fixture-specific. Successful compact MCP replies were validated against fetched advertised schemas. Target SHA-256 stayed unchanged; it was not executed.

Control: exact open PR #8397 head f07595fa1a085a57fc0c2d6de92d32f3f9d8cfcf corrects xrefs name recovery but the same four procedure operations still return schema-inspection recovery. It does not claim to fix procedure selectors.

Expected behavior

Preserve the original selector and candidate addresses, identify ambiguity as a valid lookup outcome, and recommend explicit candidate selection without schema-repair recovery. Do not silently choose a candidate or claim the inventory covers all functions.

Impact and scope

An agent receives contradictory next steps. The message itself contains the needed candidates and exact-address retry works. One unexecuted fixture, one host, one provider version and MCP compact profile were tested; CLI, other formats and actual agent choices were not tested.

REA version

a6caa79bf4f393c02601fbf2f6df246eae0b1558 and PR #8397 head above.

Runtime and platform

Node 24.22.1; macOS arm64; Kuna 1.986.

Target and artifact context

Source-owned C++ Mach-O fixture, static analysis only.

Interface

MCP.

Earliest failure stage

Native analysis or reconstruction.

Relevant output or evidence

All four messages carry both candidate addresses, while remediation advises tools/list and schema repair. Each selected-address control succeeded.

Typed outcome or recovery expected

A contract-valid selector error with candidate selection recovery and no schema-inspection recovery. Retain the exact input and unknown inventory scope.

Analysis or suspected cause

Source-derived: KunaSessionClient.#resolve creates AnalysisInputError for ambiguous procedure matches without marking the selector as conforming or supplying a specific recovery. The xref-specific branch in #8397 addresses the address selector but deliberately leaves the procedure branch unchanged.

Additional context

Related #8396 and PR #8397 concern xref name recovery; #8208 and PR #8470 address Ghidra procedure lookup; #8328 concerns independent export-to-address discovery. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Kuna 1.988 shared-alias control

On PR #8397 exact head 65939bc4ada224f10f13bd52392e987dfe23c67c, real Kuna 1.988 on macOS arm64 analyzed a source-built x86-64 ELF where audit_transform names two versioned function entries. In both full and compact stdio MCP profiles, procedure_address, procedure_assembly, procedure_callers, and analyze_function returned ambiguity with both candidate addresses and no inspect_input_contract recovery. Retrying each operation with either exact candidate succeeded in the same session. The binary SHA-256 1f158b0ea39494fcd3424844a1b02511325c567e073fbc0ed045e0bef5f0abfe stayed unchanged and it was never executed. This extends the earlier 1.986 check to one 1.988 shared-alias fixture; it does not establish general inventory completeness or autonomous-agent behavior.

Later main-derived control with Kuna 1.989

On checkout 9ebbe67e0 and Kuna 1.989 on macOS arm64, I repeated the real stdio MCP control against an unexecuted source-built Mach-O with two audit_over entries. In both compact and full profiles, all four operations reported both candidate addresses and instructed selection by exact address, without schema-inspection recovery. Retrying each operation at one of those addresses succeeded. The target SHA-256 d0b9174082cf99ba184b91558dcc1a92af11b901dac8d1a566333b6edaff3421 remained unchanged. This is evidence that the originally reported contradictory recovery is no longer reproduced for this fixture and checkout; it does not establish all selector formats or autonomous-agent behavior. The older PR head cited above is not an ancestor of this checkout, so do not infer its merge from this control.

Originally created by @morluto on GitHub (Nov 1, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8478 ### Before submitting - [x] I searched open and closed issues and pull requests for related reports. - [x] I removed credentials, private paths, and sensitive target data. ### Area Native analysis or decompilation ### Observed behavior With a valid but ambiguous Kuna procedure name, REA's error message lists both candidate addresses and asks the caller to select one. Its structured recovery simultaneously says to inspect the input schema and correct the fields. The input conforms to the schema; schema inspection does not choose a function. ### Reproduction On REA main `a6caa79bf4f393c02601fbf2f6df246eae0b1558`, Node 24.22.1, macOS arm64 and Kuna 1.986, open a source-owned arm64 Mach-O containing two C++ overloads named `audit_over`. Call `procedure_address`, `procedure_assembly`, `procedure_callers`, or `analyze_function` with `{ "procedure": "audit_over" }`. Each returns `invalid_request`, message `audit_over names 2 Kuna entries (0x1000003f8, 0x100000408); select one by address.`, and `recovery.kind: inspect_input_contract`. Calling the same operation with `procedure: "0x1000003f8"` succeeds in the same session; addresses are fixture-specific. Successful compact MCP replies were validated against fetched advertised schemas. Target SHA-256 stayed unchanged; it was not executed. Control: exact open PR #8397 head `f07595fa1a085a57fc0c2d6de92d32f3f9d8cfcf` corrects `xrefs` name recovery but the same four procedure operations still return schema-inspection recovery. It does not claim to fix procedure selectors. ### Expected behavior Preserve the original selector and candidate addresses, identify ambiguity as a valid lookup outcome, and recommend explicit candidate selection without schema-repair recovery. Do not silently choose a candidate or claim the inventory covers all functions. ### Impact and scope An agent receives contradictory next steps. The message itself contains the needed candidates and exact-address retry works. One unexecuted fixture, one host, one provider version and MCP compact profile were tested; CLI, other formats and actual agent choices were not tested. ### REA version `a6caa79bf4f393c02601fbf2f6df246eae0b1558` and PR #8397 head above. ### Runtime and platform Node 24.22.1; macOS arm64; Kuna 1.986. ### Target and artifact context Source-owned C++ Mach-O fixture, static analysis only. ### Interface MCP. ### Earliest failure stage Native analysis or reconstruction. ### Relevant output or evidence All four messages carry both candidate addresses, while remediation advises `tools/list` and schema repair. Each selected-address control succeeded. ### Typed outcome or recovery expected A contract-valid selector error with candidate selection recovery and no schema-inspection recovery. Retain the exact input and unknown inventory scope. ### Analysis or suspected cause Source-derived: `KunaSessionClient.#resolve` creates `AnalysisInputError` for ambiguous procedure matches without marking the selector as conforming or supplying a specific recovery. The xref-specific branch in #8397 addresses the `address` selector but deliberately leaves the `procedure` branch unchanged. ### Additional context Related #8396 and PR #8397 concern xref name recovery; #8208 and PR #8470 address Ghidra procedure lookup; #8328 concerns independent export-to-address discovery. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 ### Kuna 1.988 shared-alias control On PR #8397 exact head `65939bc4ada224f10f13bd52392e987dfe23c67c`, real Kuna 1.988 on macOS arm64 analyzed a source-built x86-64 ELF where `audit_transform` names two versioned function entries. In both full and compact stdio MCP profiles, `procedure_address`, `procedure_assembly`, `procedure_callers`, and `analyze_function` returned ambiguity with both candidate addresses and no `inspect_input_contract` recovery. Retrying each operation with either exact candidate succeeded in the same session. The binary SHA-256 `1f158b0ea39494fcd3424844a1b02511325c567e073fbc0ed045e0bef5f0abfe` stayed unchanged and it was never executed. This extends the earlier 1.986 check to one 1.988 shared-alias fixture; it does not establish general inventory completeness or autonomous-agent behavior. ### Later main-derived control with Kuna 1.989 On checkout `9ebbe67e0` and Kuna 1.989 on macOS arm64, I repeated the real stdio MCP control against an unexecuted source-built Mach-O with two `audit_over` entries. In both compact and full profiles, all four operations reported both candidate addresses and instructed selection by exact address, without schema-inspection recovery. Retrying each operation at one of those addresses succeeded. The target SHA-256 `d0b9174082cf99ba184b91558dcc1a92af11b901dac8d1a566333b6edaff3421` remained unchanged. This is evidence that the originally reported contradictory recovery is no longer reproduced for this fixture and checkout; it does not establish all selector formats or autonomous-agent behavior. The older PR head cited above is not an ancestor of this checkout, so do not infer its merge from this control.

bsakaguchi added the

bug

triage

labels

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

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#6622

No description provided.

Rows
Columns