morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #8688] [Bug] Parallel Kuna project Evidence omits its prototype-context limitation #7513

New issue

Closed

opened 2026-11-03 00:30:26 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-03 00:30:26 +00:00

Owner

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

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

REA records REA_KUNA_JOBS in Kuna's analysis profile and correctly separates project cache keys, but a completed parallel project pseudocode result gives the same generic limitations as a serial result. It does not explain the documented loss of callee-first prototype context when more than one worker is used.

Reproduction

On macOS arm64 with Kuna 1.988 and a self-owned arm64 C++ Mach-O, I ran decompile-project directly with --jobs 1 and --jobs 2. Both reported 22 successful functions. At 0x10000054c, jobs 1 emitted an unsigned long function returning an indirect call; jobs 2 emitted a void function that calls indirectly without a return value. Kuna's parallel run warned that signatures can differ; this is a concrete output difference, not proof of the original program's runtime behavior or which reconstruction is correct.

I repeated the same task through REA's full and compact stdio MCP profiles, using the same target and shared cache root. For each jobs value I waited for completed export with analyze_function, then called procedure_pseudo_code. Results reproduced the direct text difference. Evidence retained analysis_profile.parameters.jobs, distinct profile digests, distinct project cache keys and source file digests; both values had the same generic limitations, with no parallel prototype caveat. Successful MCP calls used fetched SDK schemas, and the target SHA-256 remained unchanged. No target was executed.

Expected behavior

For results actually produced by a parallel Kuna project export, preserve the source context and make the known worker/prototype limitation visible with the affected Evidence. Distinguish it from early single-function decompilation, which has its own limitation and is not the parallel project export. Do not report a change for every function or assert that serial is always correct.

Impact and scope

A caller can see jobs: 2 but must already know what that means to interpret a changed signature or returned value. This is one authored C++ fixture and does not establish prevalence or autonomous-agent behavior. Direct and REA results agreed on this control; this report does not allege a cache collision.

REA version

PR #8687 head 86f22cd01c2784a6630280f7876b11dd16b91fef; the documented tradeoff is in docs/kuna-provider.md.

Runtime and platform

Node 24.22.1; macOS arm64; Kuna 1.988; compact and full stdio MCP.

Target and artifact context

Self-authored ARM64 Mach-O, SHA-256 24ce215557d78193d8ceb8aa07f632686a693ad4995c3ebd5c5902c2bdd858c1.

Interface

MCP

Earliest failure stage

Completed Kuna project-result presentation.

Relevant output or evidence

The separate cache entries and profile digests differ by jobs; the parallel result has a raw_result.source.kind of project-export. The existing limitations describe generic reconstructed text, its output bound and static-analysis caveats, but not parallel worker context.

Typed outcome or recovery expected

Keep exact worker count and project source provenance, and qualify affected observations rather than altering the caller's setting. Validate both direct pseudocode and composed/retained workflows and ensure historical snapshot/cache replay does not silently acquire or lose a limitation.

Analysis or suspected cause

Source inspection: provider capability limitations are static by operation, while worker count belongs to the installation/profile and the actual result source can be either a project export or an early single-function run. Any correction should place the qualification at the source-aware boundary and propagate it through consumers without conflating those sources.

Additional context

Related #8686 (timeout recovery suggesting jobs), #8683 (automatic mode), and #8260 (per-function export provenance). CLI, other architectures, other Kuna versions and downstream workflows are untested.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 2, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8688 ### 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 REA records `REA_KUNA_JOBS` in Kuna's analysis profile and correctly separates project cache keys, but a completed parallel project pseudocode result gives the same generic limitations as a serial result. It does not explain the documented loss of callee-first prototype context when more than one worker is used. ### Reproduction On macOS arm64 with Kuna 1.988 and a self-owned arm64 C++ Mach-O, I ran `decompile-project` directly with `--jobs 1` and `--jobs 2`. Both reported 22 successful functions. At `0x10000054c`, jobs 1 emitted an `unsigned long` function returning an indirect call; jobs 2 emitted a `void` function that calls indirectly without a return value. Kuna's parallel run warned that signatures can differ; this is a concrete output difference, not proof of the original program's runtime behavior or which reconstruction is correct. I repeated the same task through REA's full and compact stdio MCP profiles, using the same target and shared cache root. For each jobs value I waited for completed export with `analyze_function`, then called `procedure_pseudo_code`. Results reproduced the direct text difference. Evidence retained `analysis_profile.parameters.jobs`, distinct profile digests, distinct project cache keys and source file digests; both values had the same generic limitations, with no parallel prototype caveat. Successful MCP calls used fetched SDK schemas, and the target SHA-256 remained unchanged. No target was executed. ### Expected behavior For results actually produced by a parallel Kuna project export, preserve the source context and make the known worker/prototype limitation visible with the affected Evidence. Distinguish it from early single-function decompilation, which has its own limitation and is not the parallel project export. Do not report a change for every function or assert that serial is always correct. ### Impact and scope A caller can see `jobs: 2` but must already know what that means to interpret a changed signature or returned value. This is one authored C++ fixture and does not establish prevalence or autonomous-agent behavior. Direct and REA results agreed on this control; this report does not allege a cache collision. ### REA version PR #8687 head `86f22cd01c2784a6630280f7876b11dd16b91fef`; the documented tradeoff is in `docs/kuna-provider.md`. ### Runtime and platform Node 24.22.1; macOS arm64; Kuna 1.988; compact and full stdio MCP. ### Target and artifact context Self-authored ARM64 Mach-O, SHA-256 `24ce215557d78193d8ceb8aa07f632686a693ad4995c3ebd5c5902c2bdd858c1`. ### Interface MCP ### Earliest failure stage Completed Kuna project-result presentation. ### Relevant output or evidence The separate cache entries and profile digests differ by jobs; the parallel result has a `raw_result.source.kind` of `project-export`. The existing limitations describe generic reconstructed text, its output bound and static-analysis caveats, but not parallel worker context. ### Typed outcome or recovery expected Keep exact worker count and project source provenance, and qualify affected observations rather than altering the caller's setting. Validate both direct pseudocode and composed/retained workflows and ensure historical snapshot/cache replay does not silently acquire or lose a limitation. ### Analysis or suspected cause Source inspection: provider capability limitations are static by operation, while worker count belongs to the installation/profile and the actual result source can be either a project export or an early single-function run. Any correction should place the qualification at the source-aware boundary and propagate it through consumers without conflating those sources. ### Additional context Related #8686 (timeout recovery suggesting jobs), #8683 (automatic mode), and #8260 (per-function export provenance). CLI, other architectures, other Kuna versions and downstream workflows are untested. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi

2026-11-03 00:30:26 +00:00

closed this issue
added the
bug

triage
labels

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#7513

No description provided.

Rows
Columns