morluto/rea

Fork 0

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

[GH-ISSUE #8191] [Bug] Bulk export labels Rust-like Kuna pseudocode as C and omits representation metadata #6473

New issue

Open

opened 2026-11-01 21:11:25 +00:00 by bsakaguchi · 6 comments

bsakaguchi commented

2026-11-01 21:11:25 +00:00

Owner

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

Before submitting

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

Area

Native analysis or decompilation; MCP and bulk export.

Observed behavior

On a source-owned Rust arm64 Mach-O, real REA/Kuna 1.986 MCP returned Rust-like pseudocode for a cold procedure_pseudo_code request and then wrote that same Rust-like text to functions/0x1000009cc.c through decompile_all. The file header correctly says the output is provider-specific pseudocode and not original source, but the .c extension suggests C syntax.

In a separate real MCP session with a fresh cache and REA_KUNA_JOBS=2, repeated requests for the same function first returned Rust-like text from a single-function run, then C-like text from the completed project export under the same analysis profile. The cold Evidence disclosed that later project text may differ; both results retain distinct Evidence IDs and source provenance. Neither response identifies the pseudocode language as a structured fact.

Reproduction

On macOS arm64, compile (without executing) a Rust binary containing this function and a main that retains a call to it:

#[no_mangle]
#[inline(never)]
pub extern "C" fn audit_compute(a: i32, b: i32) -> i32 {
    if a > 0 { a.wrapping_add(b.wrapping_mul(3)) } else { b.wrapping_sub(a) }
}
fn main() { let _ = std::hint::black_box(audit_compute(4, 5)); }

rustc --edition 2021 -C opt-level=0 -C debuginfo=1 ... produced the observed fixture, SHA-256 1c6f3e32f7e273dacf0984ae1a31f85b62968f1af3aaef65383592a2891a124a. Open it with REA/Kuna 1.986 and a fresh cache, call procedure_pseudo_code({"procedure":"_audit_compute"}) while the export builds, and call decompile_all with name: "_audit_compute" and a new output directory. To observe the transition, repeat the pseudocode call until its Evidence source changes from single-function to project-export.

Expected behavior

The result and any generated file should communicate the observed pseudocode representation without implying it is original source. Consider retaining an explicit, provider-supported language fact or using a language-neutral output extension when the language is not established. Cold and project results may legitimately differ, but their language/source distinction should be actionable for an agent and remain associated with the individual Evidence record.

Impact and scope

An editor or agent consuming the generated .c file may select a C parser for Rust-like text. A repeated request can change syntax as the project export completes. This is one fixture and one release on one host, not a claim of general semantic equivalence or compiled output correctness.

REA version

d48e472fa plus the unrelated Kuna 1.986 baseline update in #8187.

Runtime and platform

macOS arm64; Node 24.22.1; Kuna 1.986; local Rust compiler. Target was not executed.

Target and artifact context

Self-built Rust Mach-O; the affected generated file is an owned REA output artifact, not a mutation of the input binary.

Interface

Real stdio MCP, individual pseudocode and decompile_all.

Earliest failure stage

Pseudocode language/provenance projection and bulk export file naming.

Relevant output or evidence

Direct kuna decompile ... _audit_compute --json reported language: rust-language and emitted unsafe fn; direct selected kuna decompile-project wrote C-like int _audit_compute(...) into its .c project file. The same REA session observed those two representations as single-function and project-export sources. src/application/decompileDirectory/exportTree.ts assigns .c paths; functionFileText adds the explicit pseudocode header. Do not assume a file extension or language can be derived safely from the target's source language: a provider can return a different representation.

Typed outcome or recovery expected

Preserve exact provider text, Evidence identity, source and known/unknown representation. Make any chosen file naming or metadata compatible with existing decompile indexes, resume, and owned cleanup. Exercise both cold and warm paths and providers/languages whose representation is not known.

Analysis or suspected cause

The export path currently uses .c without a pseudocode-language fact. Whether to use a neutral extension, carry a provider-reported language through Evidence, or offer an explicit representation is a contract decision; this report does not propose wrapping a provider flag without validating its semantics.

Kuna 1.988 Rust-format control

With the released Kuna 1.988 executable and upstream's rust_fmt_literals_x86_64 synthetic assembly fixture (it contains an explicit Rust 1.93.1 compiler marker and controlled formatting-call patterns), direct default decompilation of literal_lf returned Rust-like println!("just a literal");. The same fixture with Kuna 1.986 or 1.988 --option rustfmtliteral off retained the explicit std::io::stdio::_print call; this is a controlled feature boundary, not a claim about compiled Rust generally.

On #8509 head 7f344af1a, real compact MCP Kuna 1.988 returned that macro on a cold procedure_pseudo_code call, with single-function source and the project export building. After the background project became ready, a second query for the same address returned C-like pseudocode with the runtime call, project-export source, and a different Evidence ID under the same analysis-profile digest. Real Ghidra 12.1.4 returned stable C-like pseudocode across its two calls. The source-kind metadata distinguishes the observations, but the availability of the 1.988 Rust rendering depends on the chosen production path. This is one controlled sequence; it does not establish semantic inequivalence. Fixture SHA-256 29a892cc34882f660ce17d36bbe54987529c04d82e5cf0751921e3b72d01a793 was unchanged; no target was executed.

As a separate non-synthetic control, self-built arm64 Mach-O dylibs using Rust 1.92.0 and 1.93.1 did not show that macro recovery in direct 1.988 Rust output. The 1.93.1 Mach-O had no embedded DWARF contents in dwarfdump; the exact reason the upstream gate did not activate was not established. Its single-function REA/Ghidra and REA/Kuna traces both found the literal and its source reference. The compiler was installed under an isolated temporary directory; the default local Rust installation stayed at 1.92.0.

Producer-supplied language and output-size boundary

Direct kuna decompile ... --json reports a top-level language (rust-language or c-language) in both released 1.986 and 1.988. In eight controlled direct calls (each version against one synthetic Rust-format ELF, two separately compiled Rust Mach-Os, and a C ELF), the JSON code matched the corresponding default text output after trailing-newline removal. A selected decompile-project control produced C-style output for the same synthetic Rust function. REA currently calls the single-function operation in text mode, so this language fact is not available to its consumer; no syntax guessing is needed if an equivalent bounded producer path is chosen.

Changing the command to JSON is not automatically equivalent at the resource boundary. The JSON includes variables, types and address mappings as well as code: in these small controls, 157–381 bytes of Rust text produced 1,145–3,481 JSON bytes, and a 69-byte C output produced 1,790 JSON bytes. REA's current KUNA_FUNCTION_TEXT_BYTES is a 16 MiB cap on captured output, so blindly retaining that cap after changing representations could reject a text result previously within its limit. These are single-fixture output measurements, not performance or prevalence claims. Any implementation should validate exact input/function identity and failure states, bound representation expansion before materialization, preserve the plain-text and completed-observation semantics, and check text/JSON equivalence and historical Evidence under real providers. The synthetic fixture and three self-built targets were unchanged and not executed.

Selected decompile-all control

Kuna 1.988 decompile ... --json --no-vars rejects --no-vars as an unknown option. The separate decompile-all <binary> --addr <entry> --json --no-vars path is accepted and reports language. On four controlled fixtures with each of Kuna 1.986 and 1.988, its selected code matched decompile --json; all 20 discovered entries of the upstream synthetic Rust-format fixture likewise matched under 1.988. This is evidence for further investigation, not proof that the commands have identical discovery, failure, whole-program prototype, scheduling or cancellation semantics.

--no-vars does not eliminate all auxiliary representation: on an unexecuted source-built arm64 Mach-O function with 500 volatile stores, the 1.988 selected code matched direct text, but the JSON retained 500 line mappings and was 68,686 bytes for 12,261 bytes of text. The target SHA-256 13104ed55381966c6baab4d728cd43f111e0cffac1456603786043a250bc67cc remained unchanged. A change to the current 16 MiB stdout boundary still needs a concrete bounded admission and partial/failure policy; these cases do not determine a general expansion bound or real-world frequency.

Address and failure boundary control

On the same source-built 500-store Mach-O with released Kuna 1.988, a direct native control compared decompile text, decompile --json, and decompile-all --addr ... --json --no-vars. All three accepted its exact code entry, an interior instruction address, and a mapped data address; the interior runs reported the address was not a discovered entry, while the data result rendered an UndefinedInstructionException stub. These direct-native inputs are not all admitted as procedure entries by current REA, so they do not establish an REA regression. For an unmapped 0x1, all three exited 1, but decompile --json returned a 209-byte JSON document with a run-level error, whereas selected decompile-all returned no stdout and an error on stderr. Failure projection therefore cannot assume a successful result document. The selected fixture SHA-256 remained unchanged; it was not executed.

Source inspection of the checked upstream development tree shows a further verification boundary: the text path invokes the console/decompiler subprocess, while decompile --json routes through the in-process decompile-all engine. The observed equal outputs above do not prove these are interchangeable under all analysis conditions. Keep command mode, source identity, errors, timeouts and cleanup attributable if evaluating a structured producer path.

Upstream interface discussion: https://github.com/Noelo-Lab/kuna/issues/1410 asks about compact structured single-function output carrying language and code, including omission semantics and failure behavior. The measured expansion and its limitations are described there.

Neutral-extension resume control

On REA 187f3d8cc with real Kuna 1.990 on macOS arm64, an owned Rust fixture produced a .c export containing Rust-like pseudocode. A copy of that export resumed successfully on the same build and skipped the existing file. In a separate temporary exploratory build, I changed the allocator and strict journal path schema to accept only .txt, then attempted the same resume on another copy. The journal was rejected as an incompatible export; the journal, index, and .c file hashes were unchanged. This experiment intentionally did not implement a migration or propose a compatibility layer. The baseline resume rewrote the derived index while leaving the journal and pseudocode file unchanged. In that same exploratory build, a fresh export wrote 0x1000009cc.txt and a second call resumed it successfully, skipping the unchanged file. This checks only the tested path, not every journal or downstream consumer.

The result establishes that an extension-only change is a persisted-format change as well as a naming change. Any design must explicitly decide how existing caller-owned exports are handled and give actionable recovery without misclassifying the caller's valid arguments as a schema error. It does not establish that a particular migration or compatibility mechanism is required. The target was not executed; this covers one fixture and host. Related journal-error guidance is being addressed separately in #8809.

Compact JSON alias expansion control

On macOS arm64, I built an unexecuted Mach-O dylib containing one two-instruction AArch64 function with 600 distinct exported names at the same address, each with a 160-character suffix. Direct Kuna 1.989 and 1.990 decompile ... 0x2a0 --addr emitted 218 bytes of text; decompile ... 0x2a0 --addr --json --omit line_mappings,variables,types emitted 114,705 bytes containing all 600 aliases, with the same code and c-language. In 1.990, adding aliases to --omit exited 2 because that omission is unsupported. The target SHA-256 cf3bbb6ecd658978ebaecc91189fbc280e9b82aedce1add7ff69333cef5053db stayed unchanged.

A separate real REA MCP session using 1.990 returned the function through its existing single-function text path (217 bytes after REA's trailing-newline removal). This intentionally extreme, source-owned fixture demonstrates that compact structured output can grow far beyond the code because of metadata that cannot currently be omitted. It does not demonstrate a natural prevalence, actual resource exhaustion, or a general expansion bound. Changing REA's existing 16 MiB stdout cap directly to compact JSON could reject an otherwise admitted text result; a design needs an explicit bounded-admission and recovery policy rather than assuming omitted line mappings and variables bound total overhead.

Upstream optional alias omission request: https://github.com/Noelo-Lab/kuna/issues/1497.

Originally created by @morluto on GitHub (Oct 30, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8191 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Native analysis or decompilation; MCP and bulk export. ### Observed behavior On a source-owned Rust arm64 Mach-O, real REA/Kuna 1.986 MCP returned Rust-like pseudocode for a cold `procedure_pseudo_code` request and then wrote that same Rust-like text to `functions/0x1000009cc.c` through `decompile_all`. The file header correctly says the output is provider-specific pseudocode and not original source, but the `.c` extension suggests C syntax. In a separate real MCP session with a fresh cache and `REA_KUNA_JOBS=2`, repeated requests for the same function first returned Rust-like text from a single-function run, then C-like text from the completed project export under the same analysis profile. The cold Evidence disclosed that later project text may differ; both results retain distinct Evidence IDs and source provenance. Neither response identifies the pseudocode language as a structured fact. ### Reproduction On macOS arm64, compile (without executing) a Rust binary containing this function and a main that retains a call to it: ```rust #[no_mangle] #[inline(never)] pub extern "C" fn audit_compute(a: i32, b: i32) -> i32 { if a > 0 { a.wrapping_add(b.wrapping_mul(3)) } else { b.wrapping_sub(a) } } fn main() { let _ = std::hint::black_box(audit_compute(4, 5)); } ``` `rustc --edition 2021 -C opt-level=0 -C debuginfo=1 ...` produced the observed fixture, SHA-256 `1c6f3e32f7e273dacf0984ae1a31f85b62968f1af3aaef65383592a2891a124a`. Open it with REA/Kuna 1.986 and a fresh cache, call `procedure_pseudo_code({"procedure":"_audit_compute"})` while the export builds, and call `decompile_all` with `name: "_audit_compute"` and a new output directory. To observe the transition, repeat the pseudocode call until its Evidence source changes from `single-function` to `project-export`. ### Expected behavior The result and any generated file should communicate the observed pseudocode representation without implying it is original source. Consider retaining an explicit, provider-supported language fact or using a language-neutral output extension when the language is not established. Cold and project results may legitimately differ, but their language/source distinction should be actionable for an agent and remain associated with the individual Evidence record. ### Impact and scope An editor or agent consuming the generated `.c` file may select a C parser for Rust-like text. A repeated request can change syntax as the project export completes. This is one fixture and one release on one host, not a claim of general semantic equivalence or compiled output correctness. ### REA version `d48e472fa` plus the unrelated Kuna 1.986 baseline update in #8187. ### Runtime and platform macOS arm64; Node 24.22.1; Kuna 1.986; local Rust compiler. Target was not executed. ### Target and artifact context Self-built Rust Mach-O; the affected generated file is an owned REA output artifact, not a mutation of the input binary. ### Interface Real stdio MCP, individual pseudocode and `decompile_all`. ### Earliest failure stage Pseudocode language/provenance projection and bulk export file naming. ### Relevant output or evidence Direct `kuna decompile ... _audit_compute --json` reported `language: rust-language` and emitted `unsafe fn`; direct selected `kuna decompile-project` wrote C-like `int _audit_compute(...)` into its `.c` project file. The same REA session observed those two representations as single-function and project-export sources. `src/application/decompileDirectory/exportTree.ts` assigns `.c` paths; `functionFileText` adds the explicit pseudocode header. Do not assume a file extension or language can be derived safely from the target's source language: a provider can return a different representation. ### Typed outcome or recovery expected Preserve exact provider text, Evidence identity, source and known/unknown representation. Make any chosen file naming or metadata compatible with existing decompile indexes, resume, and owned cleanup. Exercise both cold and warm paths and providers/languages whose representation is not known. ### Analysis or suspected cause The export path currently uses `.c` without a pseudocode-language fact. Whether to use a neutral extension, carry a provider-reported language through Evidence, or offer an explicit representation is a contract decision; this report does not propose wrapping a provider flag without validating its semantics. ### Kuna 1.988 Rust-format control With the released Kuna 1.988 executable and upstream's `rust_fmt_literals_x86_64` synthetic assembly fixture (it contains an explicit Rust 1.93.1 compiler marker and controlled formatting-call patterns), direct default decompilation of `literal_lf` returned Rust-like `println!("just a literal");`. The same fixture with Kuna 1.986 or 1.988 `--option rustfmtliteral off` retained the explicit `std::io::stdio::_print` call; this is a controlled feature boundary, not a claim about compiled Rust generally. On #8509 head `7f344af1a`, real compact MCP Kuna 1.988 returned that macro on a cold `procedure_pseudo_code` call, with `single-function` source and the project export building. After the background project became ready, a second query for the same address returned C-like pseudocode with the runtime call, `project-export` source, and a different Evidence ID under the same analysis-profile digest. Real Ghidra 12.1.4 returned stable C-like pseudocode across its two calls. The source-kind metadata distinguishes the observations, but the availability of the 1.988 Rust rendering depends on the chosen production path. This is one controlled sequence; it does not establish semantic inequivalence. Fixture SHA-256 `29a892cc34882f660ce17d36bbe54987529c04d82e5cf0751921e3b72d01a793` was unchanged; no target was executed. As a separate non-synthetic control, self-built arm64 Mach-O dylibs using Rust 1.92.0 and 1.93.1 did not show that macro recovery in direct 1.988 Rust output. The 1.93.1 Mach-O had no embedded DWARF contents in `dwarfdump`; the exact reason the upstream gate did not activate was not established. Its single-function REA/Ghidra and REA/Kuna traces both found the literal and its source reference. The compiler was installed under an isolated temporary directory; the default local Rust installation stayed at 1.92.0. ### Producer-supplied language and output-size boundary Direct `kuna decompile ... --json` reports a top-level `language` (`rust-language` or `c-language`) in both released 1.986 and 1.988. In eight controlled direct calls (each version against one synthetic Rust-format ELF, two separately compiled Rust Mach-Os, and a C ELF), the JSON `code` matched the corresponding default text output after trailing-newline removal. A selected `decompile-project` control produced C-style output for the same synthetic Rust function. REA currently calls the single-function operation in text mode, so this language fact is not available to its consumer; no syntax guessing is needed if an equivalent bounded producer path is chosen. Changing the command to JSON is not automatically equivalent at the resource boundary. The JSON includes variables, types and address mappings as well as code: in these small controls, 157–381 bytes of Rust text produced 1,145–3,481 JSON bytes, and a 69-byte C output produced 1,790 JSON bytes. REA's current `KUNA_FUNCTION_TEXT_BYTES` is a 16 MiB cap on captured output, so blindly retaining that cap after changing representations could reject a text result previously within its limit. These are single-fixture output measurements, not performance or prevalence claims. Any implementation should validate exact input/function identity and failure states, bound representation expansion before materialization, preserve the plain-text and completed-observation semantics, and check text/JSON equivalence and historical Evidence under real providers. The synthetic fixture and three self-built targets were unchanged and not executed. ### Selected decompile-all control Kuna 1.988 `decompile ... --json --no-vars` rejects `--no-vars` as an unknown option. The separate `decompile-all <binary> --addr <entry> --json --no-vars` path is accepted and reports `language`. On four controlled fixtures with each of Kuna 1.986 and 1.988, its selected code matched `decompile --json`; all 20 discovered entries of the upstream synthetic Rust-format fixture likewise matched under 1.988. This is evidence for further investigation, not proof that the commands have identical discovery, failure, whole-program prototype, scheduling or cancellation semantics. `--no-vars` does not eliminate all auxiliary representation: on an unexecuted source-built arm64 Mach-O function with 500 volatile stores, the 1.988 selected code matched direct text, but the JSON retained 500 line mappings and was 68,686 bytes for 12,261 bytes of text. The target SHA-256 `13104ed55381966c6baab4d728cd43f111e0cffac1456603786043a250bc67cc` remained unchanged. A change to the current 16 MiB stdout boundary still needs a concrete bounded admission and partial/failure policy; these cases do not determine a general expansion bound or real-world frequency. ### Address and failure boundary control On the same source-built 500-store Mach-O with released Kuna 1.988, a direct native control compared `decompile` text, `decompile --json`, and `decompile-all --addr ... --json --no-vars`. All three accepted its exact code entry, an interior instruction address, and a mapped data address; the interior runs reported the address was not a discovered entry, while the data result rendered an `UndefinedInstructionException` stub. These direct-native inputs are not all admitted as procedure entries by current REA, so they do not establish an REA regression. For an unmapped `0x1`, all three exited 1, but `decompile --json` returned a 209-byte JSON document with a run-level error, whereas selected `decompile-all` returned no stdout and an error on stderr. Failure projection therefore cannot assume a successful result document. The selected fixture SHA-256 remained unchanged; it was not executed. Source inspection of the checked upstream development tree shows a further verification boundary: the text path invokes the console/decompiler subprocess, while `decompile --json` routes through the in-process decompile-all engine. The observed equal outputs above do not prove these are interchangeable under all analysis conditions. Keep command mode, source identity, errors, timeouts and cleanup attributable if evaluating a structured producer path. Upstream interface discussion: https://github.com/Noelo-Lab/kuna/issues/1410 asks about compact structured single-function output carrying language and code, including omission semantics and failure behavior. The measured expansion and its limitations are described there. ### Neutral-extension resume control On REA `187f3d8cc` with real Kuna 1.990 on macOS arm64, an owned Rust fixture produced a `.c` export containing Rust-like pseudocode. A copy of that export resumed successfully on the same build and skipped the existing file. In a separate temporary exploratory build, I changed the allocator and strict journal path schema to accept only `.txt`, then attempted the same resume on another copy. The journal was rejected as an incompatible export; the journal, index, and `.c` file hashes were unchanged. This experiment intentionally did not implement a migration or propose a compatibility layer. The baseline resume rewrote the derived index while leaving the journal and pseudocode file unchanged. In that same exploratory build, a fresh export wrote `0x1000009cc.txt` and a second call resumed it successfully, skipping the unchanged file. This checks only the tested path, not every journal or downstream consumer. The result establishes that an extension-only change is a persisted-format change as well as a naming change. Any design must explicitly decide how existing caller-owned exports are handled and give actionable recovery without misclassifying the caller's valid arguments as a schema error. It does not establish that a particular migration or compatibility mechanism is required. The target was not executed; this covers one fixture and host. Related journal-error guidance is being addressed separately in #8809. ### Compact JSON alias expansion control On macOS arm64, I built an unexecuted Mach-O dylib containing one two-instruction AArch64 function with 600 distinct exported names at the same address, each with a 160-character suffix. Direct Kuna 1.989 and 1.990 `decompile ... 0x2a0 --addr` emitted 218 bytes of text; `decompile ... 0x2a0 --addr --json --omit line_mappings,variables,types` emitted 114,705 bytes containing all 600 aliases, with the same code and `c-language`. In 1.990, adding `aliases` to `--omit` exited 2 because that omission is unsupported. The target SHA-256 `cf3bbb6ecd658978ebaecc91189fbc280e9b82aedce1add7ff69333cef5053db` stayed unchanged. A separate real REA MCP session using 1.990 returned the function through its existing `single-function` text path (217 bytes after REA's trailing-newline removal). This intentionally extreme, source-owned fixture demonstrates that compact structured output can grow far beyond the code because of metadata that cannot currently be omitted. It does not demonstrate a natural prevalence, actual resource exhaustion, or a general expansion bound. Changing REA's existing 16 MiB stdout cap directly to compact JSON could reject an otherwise admitted text result; a design needs an explicit bounded-admission and recovery policy rather than assuming omitted line mappings and variables bound total overhead. Upstream optional alias omission request: https://github.com/Noelo-Lab/kuna/issues/1497.

bsakaguchi added the

bug

triage

labels

2026-11-01 21:11:25 +00:00

bsakaguchi commented

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

Author

Owner

@sathariels commented on GitHub (Oct 30, 2026):

I'd like to take this one. My plan: carry a provider-reported pseudocode language through to the pseudocode result and Evidence record as an explicit field (unknown when the provider doesn't establish it), and have decompile_all pick the file extension from that fact — .rs/.c only when the language is known, otherwise a language-neutral extension such as .pseudo — while keeping existing decompile indexes, resume and owned cleanup working with older .c exports. Happy to adjust if you'd prefer a different contract (e.g. always neutral extension + language in the index only).

@sathariels commented on GitHub (Oct 30, 2026): I'd like to take this one. My plan: carry a provider-reported pseudocode language through to the pseudocode result and Evidence record as an explicit field (`unknown` when the provider doesn't establish it), and have `decompile_all` pick the file extension from that fact — `.rs`/`.c` only when the language is known, otherwise a language-neutral extension such as `.pseudo` — while keeping existing decompile indexes, resume and owned cleanup working with older `.c` exports. Happy to adjust if you'd prefer a different contract (e.g. always neutral extension + language in the index only).

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 30, 2026):

A separate real MCP cold-to-warm bulk-export sequence makes the lifecycle explicit. With a fresh Kuna cache and two workers, decompile_all selected and wrote the Rust-like cold body. After the project export became ready and procedure_pseudo_code returned C-like project text, decompile_all with resume: true on the existing output reported skipped: 1 and kept the verified original Rust-like file; a new output directory wrote the C-like body. Both files had .c extensions, and the cold file/index retained the single-function limitation.

Skipping the verified file is consistent with the advertised resume contract; this is not a request to silently overwrite it. It demonstrates why representation and source information need to remain per produced artifact and why a caller may need an explicit fresh output to obtain the current project representation.

@morluto commented on GitHub (Oct 30, 2026): A separate real MCP cold-to-warm bulk-export sequence makes the lifecycle explicit. With a fresh Kuna cache and two workers, `decompile_all` selected and wrote the Rust-like cold body. After the project export became ready and `procedure_pseudo_code` returned C-like project text, `decompile_all` with `resume: true` on the existing output reported `skipped: 1` and kept the verified original Rust-like file; a new output directory wrote the C-like body. Both files had `.c` extensions, and the cold file/index retained the single-function limitation. Skipping the verified file is consistent with the advertised resume contract; this is not a request to silently overwrite it. It demonstrates why representation and source information need to remain per produced artifact and why a caller may need an explicit fresh output to obtain the current project representation.

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

@morluto commented on GitHub (Oct 31, 2026): Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0 for visibility on the Ghidra, Kuna, and REA tool-design investigation.

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

One more control for the representation contract on REA 245a5818, Kuna 1.986, and the same unexecuted Rust Mach-O:

Direct Kuna invocation	Reported language	Observed text
`decompile … _audit_compute --json` (language omitted)	`rust-language`	Rust-like
Same, `--language auto`	`c-language`	C-like
Same, `--language c`	`c-language`	C-like
Same, `--language rust`	`rust-language`	Rust-like

This is one target and provider version. The v1.986 argument handling sets saw_language even for auto; the automatic detection policy only runs when no language was specified and deliberately excludes project exports. If a future REA design offers language selection, omission and explicit auto therefore need distinct treatment; the returned representation should be attached to the actual producing observation rather than inferred from target language or shared profile.

In a fresh real REA/Kuna MCP session, the cold procedure_pseudo_code returned Rust-like single-function output; analyze_function waited for the project export and returned C-like text. Their analysis profiles matched, while their source and retained Evidence identities differed. compare_functions correctly rejected the cold record because its documented inputs require analyze_function Evidence. Explicitly pairing the cold and warm pseudocode records via compare_bundles reported that the records changed, with overall status unknown because other bundle members were one-sided; it did not identify the textual change or establish a behavioral difference. This is an existing narrower comparison path, not a request to treat incomplete pseudocode records as full function dossiers. The target digest was unchanged.

@morluto commented on GitHub (Oct 31, 2026): One more control for the representation contract on REA `245a5818`, Kuna 1.986, and the same unexecuted Rust Mach-O: | Direct Kuna invocation | Reported language | Observed text | | --- | --- | --- | | `decompile … _audit_compute --json` (language omitted) | `rust-language` | Rust-like | | Same, `--language auto` | `c-language` | C-like | | Same, `--language c` | `c-language` | C-like | | Same, `--language rust` | `rust-language` | Rust-like | This is one target and provider version. The [v1.986 argument handling](https://github.com/Noelo-Lab/kuna/blob/v1.986/decompiler/crates/kuna-cli/src/decompile_all.rs#L2670-L2678) sets `saw_language` even for `auto`; the [automatic detection policy](https://github.com/Noelo-Lab/kuna/blob/v1.986/decompiler/crates/kuna-cli/src/decompile_all.rs#L2746-L2762) only runs when no language was specified and deliberately excludes project exports. If a future REA design offers language selection, omission and explicit `auto` therefore need distinct treatment; the returned representation should be attached to the actual producing observation rather than inferred from target language or shared profile. In a fresh real REA/Kuna MCP session, the cold `procedure_pseudo_code` returned Rust-like single-function output; `analyze_function` waited for the project export and returned C-like text. Their analysis profiles matched, while their source and retained Evidence identities differed. `compare_functions` correctly rejected the cold record because its documented inputs require `analyze_function` Evidence. Explicitly pairing the cold and warm pseudocode records via `compare_bundles` reported that the records changed, with overall status `unknown` because other bundle members were one-sided; it did not identify the textual change or establish a behavioral difference. This is an existing narrower comparison path, not a request to treat incomplete pseudocode records as full function dossiers. The target digest was unchanged.

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

CLI control on REA e6d0618979f0df3f1d5db218b0fc7b5e6a9cf3f9, Kuna 1.986, and the same unexecuted Rust Mach-O:

Two separate rea decompile <target> _audit_compute --provider kuna --format json --full-output commands with the same initially fresh cache each returned Rust-like single-function text and a project_export.state: building observation. The response included the existing caveat that later project text can differ. A separate single cold CLI invocation left its isolated projects and staging directories empty after the command exited; this is not evidence that every CLI invocation or every target will remain cold.
Running rea function <target> _audit_compute --provider kuna --format json --full-output against that second cache completed successfully and returned C-like function-dossier pseudocode. A subsequent separate rea decompile using that cache returned C-like project-export text with state: ready. Independently, priming the first cache through MCP analyze_function also made a later CLI decompile use the project export.

The ordinary CLI rendering retained the cold source and caveat as well. These observations give a tested CLI-only route for an analyst who needs the project-produced representation; they do not imply that function is simply a language switch, that the outputs are behaviorally equivalent, or that an agent should silently force a whole-project export. The source says session close cancels its export interest and waits for required cleanup, which is consistent with the isolated cold-directory observation. Target SHA-256 stayed unchanged. Please consider the cold one-shot / warm cached transition alongside per-artifact representation when evaluating the existing proposal.

@morluto commented on GitHub (Oct 31, 2026): CLI control on REA `e6d0618979f0df3f1d5db218b0fc7b5e6a9cf3f9`, Kuna 1.986, and the same unexecuted Rust Mach-O: 1. Two separate `rea decompile <target> _audit_compute --provider kuna --format json --full-output` commands with the same initially fresh cache each returned Rust-like `single-function` text and a `project_export.state: building` observation. The response included the existing caveat that later project text can differ. A separate single cold CLI invocation left its isolated `projects` and `staging` directories empty after the command exited; this is not evidence that every CLI invocation or every target will remain cold. 2. Running `rea function <target> _audit_compute --provider kuna --format json --full-output` against that second cache completed successfully and returned C-like function-dossier pseudocode. A subsequent separate `rea decompile` using that cache returned C-like `project-export` text with `state: ready`. Independently, priming the first cache through MCP `analyze_function` also made a later CLI `decompile` use the project export. The ordinary CLI rendering retained the cold source and caveat as well. These observations give a tested CLI-only route for an analyst who needs the project-produced representation; they do not imply that `function` is simply a language switch, that the outputs are behaviorally equivalent, or that an agent should silently force a whole-project export. The source says session close cancels its export interest and waits for required cleanup, which is consistent with the isolated cold-directory observation. Target SHA-256 stayed unchanged. Please consider the cold one-shot / warm cached transition alongside per-artifact representation when evaluating the existing proposal.

bsakaguchi commented

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

Author

Owner

@morluto commented on GitHub (Oct 31, 2026):

A related real-provider control shows that the cold/project representation transition can occur inside one batch_decompile response for an ordinary function. In a small owned Rust Mach-O, a test wrapper held the project export until the first single-function result completed; repeated _audit_compute selections returned Rust-like and C-like bodies, both successful. Direct Kuna reported rust-language for the first text, and a later individual REA request identified the matching C-like text as project-export output. Successful batch items did not identify their source or representation. Real Ghidra returned equal repeated bodies on the same fixture. Details, scheduling limitations and offline Evidence control: #8350. This is one intentionally scheduled test and does not imply a natural rate or semantic equivalence.

@morluto commented on GitHub (Oct 31, 2026): A related real-provider control shows that the cold/project representation transition can occur **inside one** `batch_decompile` response for an ordinary function. In a small owned Rust Mach-O, a test wrapper held the project export until the first single-function result completed; repeated `_audit_compute` selections returned Rust-like and C-like bodies, both successful. Direct Kuna reported `rust-language` for the first text, and a later individual REA request identified the matching C-like text as project-export output. Successful batch items did not identify their source or representation. Real Ghidra returned equal repeated bodies on the same fixture. Details, scheduling limitations and offline Evidence control: #8350. This is one intentionally scheduled test and does not imply a natural rate or semantic equivalence.

bsakaguchi referenced this issue

2026-11-01 21:47:36 +00:00

[PR #6744] [CLOSED] fix(objdump): name the rejected field in inspect-with-objdump input errors #7404

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

No description provided.

Rows
Columns