morluto/rea

Fork 0

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

[GH-ISSUE #8319] [Design] Define Kuna cache identity for caller-configured launchers #6542

New issue

Open

opened 2026-11-01 21:12:05 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

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

Owner

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

Decision needed

How should REA let a caller identify or refresh a Kuna analysis when a selected launcher depends on configuration or executables outside the launcher file? How should agents learn what cache identity does and does not establish?

Context and evidence

Observed: On macOS arm64, using real Kuna 1.986 and REA b43c329 (the Kuna source is unchanged through origin/main 23de10b), I selected a local shell launcher via REA_KUNA_COMMAND. The launcher forwards to the official Kuna executable and adds --mode to decompile-project using a separate caller-owned text file. The target, launcher and official executable bytes stayed unchanged.

With the mode file set to reliable, open_binary followed by procedure_pseudo_code built an export and returned float4 _audit_float(float4 a0).
I changed the mode file to aggressive and started a new MCP server with the same cache. REA returned the same float4 text and Evidence ID; the launcher's project-invocation log showed that it did not run decompile-project again.
With the mode still aggressive, a third server using a new empty REA_KUNA_CACHE_DIR ran the export and returned float _audit_float(float a0). Independent direct Kuna exports gave the same mode-dependent difference. All three REA results used the same analysis-profile digest and project key; the exported C-file digests differed between the first and third runs.

This is an intentionally instrumented launcher, not a claim about how often users configure Kuna this way. REA was not told about the external file and cannot infer arbitrary launcher dependencies. verified_release: true in this case means the launcher reported the verified version; it does not authenticate the executable or establish its configuration.

Source-derived: The cache key includes the target, selected executable hash/paths, version and jobs, but no caller-supplied identity for external launcher inputs. The provider guide describes those key inputs and warm reuse. File-digest verification validates the retained export, not whether unknown launcher inputs changed. Selecting a separate empty cache was a successful workaround in this test.

Expected interaction with targets

Read existing files or captured data; write REA-owned cache files. The experiment did not execute or modify the target.

Options and tradeoffs

Consider explicit caller-provided cache identity, a caller-selected refresh/bypass, or clearer guidance on the launcher dependency boundary and existing cache-directory workaround. These are design options, not a request to inspect arbitrary launcher dependencies, capture ambient environment values, or silently change analysis settings. Any identity should carry through to Evidence if it affects results.

Verification available so far

I have a prototype or observed results. The reproduction used a small locally built Mach-O fixture, one instrumented launcher, the real release and MCP; other platforms, provider versions and launcher patterns were not tested. A public-workflow regression could vary a caller-declared input across sessions and confirm both refresh and Evidence provenance if a contract is adopted.

Additional snapshot boundary observation

On a fresh macOS arm64 run using real Kuna 1.986 and the branch for #8485, I saved a snapshot after a reliable analysis, changed the launcher mode to aggressive, and reopened the same target and snapshot with a separate empty cache. REA accepted the snapshot and produced the aggressive pseudocode from a new export. Both results had the same analysis-profile digest, though their pseudocode and export file digests differed. The saved snapshot contained two Evidence records and zero primitive or workflow entries, so this does not reproduce stale snapshot replay. It shows that cache-directory isolation alone refreshes the export but does not distinguish the caller-controlled launcher configuration in the profile used for snapshot binding. Target, launcher, and Kuna executable hashes stayed unchanged in the accompanying three-session cache reproduction.

A subsequent MCP control ran binary_overview and analyze_function across the same mode change and separate caches. Its saved snapshot contained three Evidence records and zero primitive or workflow replay entries. Source inspection shows Kuna declares cache_policy: live, and the snapshot-cache admission excludes live capabilities from replay. These observations narrow the tested problem to export reuse and configuration provenance; they do not establish stale replay for Kuna.

Same-session configuration change control

On real Kuna 1.986, I preloaded the function inventory and used a deliberately gated launcher to pause a cold project export. While that export waited, a single-function decompile ran in reliable mode and returned float4. I changed the launcher's separate mode file to aggressive, released the export, and repeated the same pseudocode request: the project export returned float. Both observations had the same analysis-profile digest. REA did identify their different source kinds, and the first explicitly warned that later project-export text can differ. A separate same-setting control used reliable for both and returned float4 in both cases. Target, launcher and Kuna executable hashes remained unchanged; the target was not executed.

This controlled case also means a caller-declared identity alone cannot detect configuration changes during a session. Any such contract needs to state the caller's responsibility to keep declared external inputs stable, or to start a new session with a new identity when they change; it must not promise automatic dependency monitoring.

References

Related version guidance: #8317. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Oct 31, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8319 ### Decision needed How should REA let a caller identify or refresh a Kuna analysis when a selected launcher depends on configuration or executables outside the launcher file? How should agents learn what cache identity does and does not establish? ### Context and evidence **Observed:** On macOS arm64, using real Kuna 1.986 and REA `b43c329` (the Kuna source is unchanged through `origin/main` `23de10b`), I selected a local shell launcher via `REA_KUNA_COMMAND`. The launcher forwards to the official Kuna executable and adds `--mode` to `decompile-project` using a separate caller-owned text file. The target, launcher and official executable bytes stayed unchanged. 1. With the mode file set to `reliable`, `open_binary` followed by `procedure_pseudo_code` built an export and returned `float4 _audit_float(float4 a0)`. 2. I changed the mode file to `aggressive` and started a new MCP server with the same cache. REA returned the same `float4` text and Evidence ID; the launcher's project-invocation log showed that it did not run `decompile-project` again. 3. With the mode still `aggressive`, a third server using a new empty `REA_KUNA_CACHE_DIR` ran the export and returned `float _audit_float(float a0)`. Independent direct Kuna exports gave the same mode-dependent difference. All three REA results used the same analysis-profile digest and project key; the exported C-file digests differed between the first and third runs. This is an intentionally instrumented launcher, not a claim about how often users configure Kuna this way. REA was not told about the external file and cannot infer arbitrary launcher dependencies. `verified_release: true` in this case means the launcher reported the verified version; it does not authenticate the executable or establish its configuration. **Source-derived:** [The cache key](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/src/kuna/KunaProjectCache.ts#L78-L108) includes the target, selected executable hash/paths, version and jobs, but no caller-supplied identity for external launcher inputs. The [provider guide](https://github.com/morluto/rea/blob/b43c329df779708e43ae297f498a844e45d9c923/docs/kuna-provider.md#L54-L56) describes those key inputs and warm reuse. File-digest verification validates the retained export, not whether unknown launcher inputs changed. Selecting a separate empty cache was a successful workaround in this test. ### Expected interaction with targets Read existing files or captured data; write REA-owned cache files. The experiment did not execute or modify the target. ### Options and tradeoffs Consider explicit caller-provided cache identity, a caller-selected refresh/bypass, or clearer guidance on the launcher dependency boundary and existing cache-directory workaround. These are design options, not a request to inspect arbitrary launcher dependencies, capture ambient environment values, or silently change analysis settings. Any identity should carry through to Evidence if it affects results. ### Verification available so far I have a prototype or observed results. The reproduction used a small locally built Mach-O fixture, one instrumented launcher, the real release and MCP; other platforms, provider versions and launcher patterns were not tested. A public-workflow regression could vary a caller-declared input across sessions and confirm both refresh and Evidence provenance if a contract is adopted. ### Additional snapshot boundary observation On a fresh macOS arm64 run using real Kuna 1.986 and the branch for #8485, I saved a snapshot after a `reliable` analysis, changed the launcher mode to `aggressive`, and reopened the same target and snapshot with a separate empty cache. REA accepted the snapshot and produced the aggressive pseudocode from a new export. Both results had the same analysis-profile digest, though their pseudocode and export file digests differed. The saved snapshot contained two Evidence records and zero primitive or workflow entries, so this does **not** reproduce stale snapshot replay. It shows that cache-directory isolation alone refreshes the export but does not distinguish the caller-controlled launcher configuration in the profile used for snapshot binding. Target, launcher, and Kuna executable hashes stayed unchanged in the accompanying three-session cache reproduction. A subsequent MCP control ran `binary_overview` and `analyze_function` across the same mode change and separate caches. Its saved snapshot contained three Evidence records and zero primitive or workflow replay entries. Source inspection shows Kuna declares `cache_policy: live`, and the snapshot-cache admission excludes live capabilities from replay. These observations narrow the tested problem to export reuse and configuration provenance; they do not establish stale replay for Kuna. ### Same-session configuration change control On real Kuna 1.986, I preloaded the function inventory and used a deliberately gated launcher to pause a cold project export. While that export waited, a single-function decompile ran in `reliable` mode and returned `float4`. I changed the launcher's separate mode file to `aggressive`, released the export, and repeated the same pseudocode request: the project export returned `float`. Both observations had the same analysis-profile digest. REA did identify their different source kinds, and the first explicitly warned that later project-export text can differ. A separate same-setting control used `reliable` for both and returned `float4` in both cases. Target, launcher and Kuna executable hashes remained unchanged; the target was not executed. This controlled case also means a caller-declared identity alone cannot detect configuration changes during a session. Any such contract needs to state the caller's responsibility to keep declared external inputs stable, or to start a new session with a new identity when they change; it must not promise automatic dependency monitoring. ### References Related version guidance: #8317. @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):

Agent-recovery follow-up: I tested the public search_guidance and read_guidance_section tools on REA b43c329, with installed guidance rea-agents@6.8.0, without opening a target. kuna refresh cache, REA_KUNA_CACHE_DIR, and kuna launcher returned no matches. stale kuna cache returned Connect only when needed first (4,037 characters); that section did not name REA_KUNA_CACHE_DIR or explain the project-cache workaround. kuna project export returned the 34,995-character root skill section, which links to the provider guide but does not name that setting. This is a small set of fixed queries, not a claim that agents cannot find the linked guide or that autonomous recovery fails.

The provider guide does document REA_KUNA_CACHE_DIR; the separate-empty-directory workaround in the original report was tested directly. If the cache contract changes, consider whether its recovery and identity limits need a focused, discoverable agent recipe too. The broad-parent ranking aspect is already tracked in #8290.

@morluto commented on GitHub (Oct 31, 2026): Agent-recovery follow-up: I tested the public `search_guidance` and `read_guidance_section` tools on REA `b43c329`, with installed guidance `rea-agents@6.8.0`, without opening a target. `kuna refresh cache`, `REA_KUNA_CACHE_DIR`, and `kuna launcher` returned no matches. `stale kuna cache` returned `Connect only when needed` first (4,037 characters); that section did not name `REA_KUNA_CACHE_DIR` or explain the project-cache workaround. `kuna project export` returned the 34,995-character root skill section, which links to the provider guide but does not name that setting. This is a small set of fixed queries, not a claim that agents cannot find the linked guide or that autonomous recovery fails. The provider guide does document `REA_KUNA_CACHE_DIR`; the separate-empty-directory workaround in the original report was tested directly. If the cache contract changes, consider whether its recovery and identity limits need a focused, discoverable agent recipe too. The broad-parent ranking aspect is already tracked in #8290.

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

No description provided.

Rows
Columns