morluto/rea

Fork 0

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

[GH-ISSUE #8317] [Design] Make unverified Kuna release guidance discoverable to MCP callers #6541

New issue

Open

opened 2026-11-01 21:12:04 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

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

Owner

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

Before submitting

I searched the open and closed issues and pull requests for a related discussion.
I understand the contribution scope must be reviewed before integration; open questions are welcome here.
This discussion does not include credentials, private samples, or sensitive target data.

Decision needed

How should an MCP-only caller interpret an explicitly selected unverified Kuna release and discover the verified baseline and optional recovery, while preserving the caller's chosen executable and continuing to allow other releases?

Context and evidence

On REA b43c329df779708e43ae297f498a844e45d9c923, Node 24.22.1, macOS arm64, I configured official Kuna 1.833 and 1.986 separately via REA_KUNA_COMMAND and used a self-built arm64 Mach-O. Both real MCP sessions opened, returned pseudocode and closed; the target hash stayed unchanged and it was not executed. The requested executable, version and hash were preserved in each analysis profile; verified_release was respectively false and true.

Scoped CLI rea doctor --provider kuna --target <target> --format json for 1.833 returned a healthy usable provider while naming verified 1.986, explaining that this version's project layout is unverified, giving the REA_KUNA_COMMAND / restart route, and explicitly saying the selected release may be continued. With 1.986, the verified control had no version-change recommendation.

In real MCP, binary_session summary and complete and procedure_pseudo_code retained the verified_release: false boolean but, in this run, did not say what it meant, identify the verified baseline or provide the doctor's version-selection guidance. The provider candidate was available; no tool-level error was appropriate because the chosen release worked. search_guidance({query:"kuna unverified"}) returned no bundled match; kuna verified release returned a broad parent whose returned text contained no 1.986 or unverified. These are the queries tested, not proof that a caller cannot find the external guide or run the CLI. No autonomous-agent behavior was measured.

Expected interaction with targets

Read existing local targets and use the caller-selected Kuna executable. No installation, upgrade, target execution or automatic provider/version change is proposed.

Boundary details (optional)

Preserve the selected executable path, hash, version and profile identity. Unverified is not unsupported or failed; verified is scoped to the release/hosts actually tested, not a guarantee of correctness on every host or target. Do not install, upgrade, pin or silently switch the user's executable.

Options and tradeoffs

Compare exposing a concise provider readiness/verification note with optional baseline and recovery in binary_session, improving bundled guidance, or documenting that CLI doctor is the intended source. Avoid repeating large warnings on every function result and consider profile/cache identity, context cost, other providers and SDK schemas. A precise contract is open for discussion.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Exercise verified and unverified real releases through CLI/MCP, preserved caller configuration, selected executable identity, unsupported and missing providers, target-free session discovery and updated schemas. Verify no automatic install or switch and report host/release verification scope. The observations here are one target and macOS arm64, not a broad compatibility or agent-selection study.

References

#8187 introduced the verified baseline and CLI doctor guidance; Kuna provider guide describes other releases as unverified.

Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8317 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related discussion. - [x] I understand the contribution scope must be reviewed before integration; open questions are welcome here. - [x] This discussion does not include credentials, private samples, or sensitive target data. ### Decision needed How should an MCP-only caller interpret an explicitly selected unverified Kuna release and discover the verified baseline and optional recovery, while preserving the caller's chosen executable and continuing to allow other releases? ### Context and evidence On REA `b43c329df779708e43ae297f498a844e45d9c923`, Node 24.22.1, macOS arm64, I configured official Kuna 1.833 and 1.986 separately via `REA_KUNA_COMMAND` and used a self-built arm64 Mach-O. Both real MCP sessions opened, returned pseudocode and closed; the target hash stayed unchanged and it was not executed. The requested executable, version and hash were preserved in each analysis profile; `verified_release` was respectively `false` and `true`. Scoped CLI `rea doctor --provider kuna --target <target> --format json` for 1.833 returned a healthy usable provider while naming verified 1.986, explaining that this version's project layout is unverified, giving the `REA_KUNA_COMMAND` / restart route, and explicitly saying the selected release may be continued. With 1.986, the verified control had no version-change recommendation. In real MCP, `binary_session` summary **and** complete and `procedure_pseudo_code` retained the `verified_release: false` boolean but, in this run, did not say what it meant, identify the verified baseline or provide the doctor's version-selection guidance. The provider candidate was `available`; no tool-level error was appropriate because the chosen release worked. `search_guidance({query:"kuna unverified"})` returned no bundled match; `kuna verified release` returned a broad parent whose returned text contained no `1.986` or `unverified`. These are the queries tested, not proof that a caller cannot find the external guide or run the CLI. No autonomous-agent behavior was measured. ### Expected interaction with targets Read existing local targets and use the caller-selected Kuna executable. No installation, upgrade, target execution or automatic provider/version change is proposed. ### Boundary details (optional) Preserve the selected executable path, hash, version and profile identity. Unverified is not unsupported or failed; verified is scoped to the release/hosts actually tested, not a guarantee of correctness on every host or target. Do not install, upgrade, pin or silently switch the user's executable. ### Options and tradeoffs Compare exposing a concise provider readiness/verification note with optional baseline and recovery in `binary_session`, improving bundled guidance, or documenting that CLI doctor is the intended source. Avoid repeating large warnings on every function result and consider profile/cache identity, context cost, other providers and SDK schemas. A precise contract is open for discussion. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Exercise verified and unverified real releases through CLI/MCP, preserved caller configuration, selected executable identity, unsupported and missing providers, target-free session discovery and updated schemas. Verify no automatic install or switch and report host/release verification scope. The observations here are one target and macOS arm64, not a broad compatibility or agent-selection study. ### References [#8187](https://github.com/morluto/rea/pull/8187) introduced the verified baseline and CLI doctor guidance; [Kuna provider guide](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/docs/kuna-provider.md) describes other releases as unverified. Looping in @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0.

bsakaguchi added the

enhancement

triage

labels

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

bsakaguchi commented

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

Author

Owner

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

Shared-cache version identity control

Using a new shared REA Kuna cache root and the same owned unexecuted Mach-O, I ran real stdio MCP sessions with explicitly selected Kuna 1.833, then 1.986, then 1.833 again. Each requested assembly to await the project export and then pseudocode; all calls and closes succeeded.

The two releases produced distinct analysis-profile digests and project-export keys. Their cache manifests recorded the corresponding executable SHA-256, command and version. Returning to 1.833 selected the first version's same key and profile. On this small fixture the resulting .c and .asm file hashes happened to agree across the two versions; that is not evidence that releases are generally equivalent. Repeated key selection also does not independently prove no rebuild occurred.

Both selected executables and the target retained their hashes, and the target was not executed. This supports preserving selected-version/cache identity while improving the unverified-release guidance discussed here; it does not justify automatic upgrades or compatibility branches.

@morluto commented on GitHub (Oct 31, 2026): ### Shared-cache version identity control Using a new shared REA Kuna cache root and the same owned unexecuted Mach-O, I ran real stdio MCP sessions with explicitly selected Kuna 1.833, then 1.986, then 1.833 again. Each requested assembly to await the project export and then pseudocode; all calls and closes succeeded. The two releases produced distinct analysis-profile digests and project-export keys. Their cache manifests recorded the corresponding executable SHA-256, command and version. Returning to 1.833 selected the first version's same key and profile. On this small fixture the resulting `.c` and `.asm` file hashes happened to agree across the two versions; that is not evidence that releases are generally equivalent. Repeated key selection also does not independently prove no rebuild occurred. Both selected executables and the target retained their hashes, and the target was not executed. This supports preserving selected-version/cache identity while improving the unverified-release guidance discussed here; it does not justify automatic upgrades or compatibility branches.

bsakaguchi commented

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

Author

Owner

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

Meaning of the verified flag

A control used a caller-owned transparent shell wrapper that execs the official Kuna 1.986 executable unchanged. Real REA CLI doctor and MCP accepted both the direct executable and wrapper, and both profiles reported version 1.986 / verified_release: true. The selected wrapper had a different SHA-256, and REA preserved that wrapper's own selected path/hash and a different project-export key. Assembly and pseudocode worked in both sessions. The wrapper, real executable and target hashes were unchanged, and the target was not executed.

Source inspection shows the flag compares the reported version with KUNA_VERIFIED_VERSION; it is not a digest allowlist or distribution-authenticity check. The earlier closed #5611 explicitly makes the same distinction. Any explanatory text for this issue should keep that scope precise: it can say REA verified that release version on the documented host, but should not imply each caller-supplied executable's bytes were authenticated as an official release. This control is not a claim that the wrapper is malicious or that either decompilation is correct for arbitrary targets.

@morluto commented on GitHub (Oct 31, 2026): ### Meaning of the verified flag A control used a caller-owned transparent shell wrapper that `exec`s the official Kuna 1.986 executable unchanged. Real REA CLI doctor and MCP accepted both the direct executable and wrapper, and both profiles reported version `1.986` / `verified_release: true`. The selected wrapper had a different SHA-256, and REA preserved that wrapper's own selected path/hash and a different project-export key. Assembly and pseudocode worked in both sessions. The wrapper, real executable and target hashes were unchanged, and the target was not executed. Source inspection shows the flag compares the reported version with `KUNA_VERIFIED_VERSION`; it is **not** a digest allowlist or distribution-authenticity check. The earlier closed #5611 explicitly makes the same distinction. Any explanatory text for this issue should keep that scope precise: it can say REA verified that release version on the documented host, but should not imply each caller-supplied executable's bytes were authenticated as an official release. This control is not a claim that the wrapper is malicious or that either decompilation is correct for arbitrary targets.

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

No description provided.

Rows
Columns