morluto/rea

Fork 0

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

[PR #4066] [CLOSED] fix(kuna): run the inventory with the configured decode lanes #6033

New issue

Closed

opened 2026-10-31 01:11:20 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:11:20 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/4066
Author: @kaoru0822-kitauji
Created: 10/15/2026
Status: ❌ Closed

Base: main ← Head: fix/kuna-inventory-honors-jobs

📝 Commits (1)

225d664 fix(kuna): run the inventory with the configured decode lanes

📊 Changes

6 files changed (+53 additions, -11 deletions)

View changed files

📝 docs/kuna-provider.md (+8 -8)
📝 src/kuna/KunaCommand.ts (+10 -0)
📝 src/kuna/KunaProjectExport.ts (+2 -1)
📝 src/kuna/KunaSessionClient.ts (+5 -1)
📝 tests/boundary/providers/kuna/kunaProjectCache.test.ts (+7 -1)
📝 tests/boundary/providers/kuna/kunaProvider.test.ts (+21 -0)

📄 Description

Summary

REA_KUNA_JOBS reached only kuna decompile-project. The export's first step, the kuna functions --json inventory that every cold request waits for (listings, lookups, and name or address resolution before a single-function decompile), always ran serially, and so did the session's own inventory run. Kuna documents functions --jobs N as returning "the serial one byte for byte" inventory from N decode lanes. Raising REA_KUNA_JOBS therefore left the slowest blocking step untouched. Refs #1957.

Problem and expected behavior

Smallest trigger: REA_KUNA_JOBS=8, cold cache, any first request on a large image. Observed: kuna functions <copy> --json without --jobs, at 66 s for a 254 MB Mach-O. Expected: the inventory uses the configured decode lanes, because its output cannot change.

Change and scope

New kunaInventoryArguments(input, jobs) in KunaCommand.ts builds the one kuna functions … --json --jobs N command line. The export's inventory step and the session's own inventory run both use it, so the command is no longer written out twice.
docs/kuna-provider.md: the REA_KUNA_JOBS row says it applies to both commands and that the inventory is identical for any value.
Default unchanged: REA_KUNA_JOBS stays 1, and --jobs 1 produced a byte-identical inventory on zip (cmp).

Not included: no new setting and no change to the default. Parallel lanes raised the inventory's peak RSS on Telegram (6413 MiB with 8 lanes vs 3889 MiB serially, measured outside REA), so lanes stay opt-in through the existing setting. The cache key already includes jobs. #4062 (export inventory sharing) is independent; together, a cold first request runs one inventory with the configured lanes.

Scope: an ordinary fix within the existing Kuna provider boundary; no maintainer scope decision applies.

Contract and boundary impact

Semantic owner and earliest changed stage: KunaCommand.kunaInventoryArguments, used by exportKunaProject and KunaSessionClient.
Contribution scope fit and linked maintainer decision: not applicable.
CLI and MCP/tool-catalog contract: unchanged. Same inventory content.
Provider, bridge, target-format, or platform compatibility: Kuna only. --jobs is a kuna functions option in the verified 1.833.
Evidence, artifact, provenance, or reconstruction contract: unchanged. The inventory is identical, and the export key already includes jobs.
Target selection, authority, upstream behavior, and cleanup details: the same owned process, with more decode lanes inside it when configured.
Generated metadata, package, or installation impact: none.

Expected effects:

Read existing files or captured data.
Launch or attach to a process.
Inject instrumentation or run scripts/code.
Change process memory, registers, files, or configuration.
Contact network services.
Recover protected code or work around protections.
Documentation or usability only; no target interaction.
Not sure yet; investigation or maintainer guidance needed.

(Existing kuna functions runs gain --jobs.)

Evidence and regression coverage

Tests added or updated: kunaProvider.test.ts gets "runs every inventory with the configured decode lanes": with REA_KUNA_JOBS=4, every functions call ends with --json --jobs 4 and the export with --jobs 4. kunaProjectCache.test.ts now expects --jobs 1 on the export's inventory at the default.
Base reproduction: both tests fail on the base revision (git stash of src/kuna).

Kuna's equivalence claim, checked directly on /Applications/Telegram.app/Contents/MacOS/Telegram (thin arm64, 254 MB, 696,944 entries) with Kuna 1.833, outside REA:

`kuna functions --json`	Wall	User CPU	Peak RSS	`functions` equal to serial
serial	65.7 s	61.9 s	3889 MiB	—
`--jobs 4`	30.2 s	84.5 s	6765 MiB	yes
`--jobs 8`	23.4 s	105.7 s	6413 MiB	yes
`--jobs auto` (10 lanes)	23.0 s	107.5 s	6679 MiB	yes

Through REA, MCP cold search_procedures on the same binary with REA_KUNA_JOBS=8, one run per build:

Build search_procedures Process wall Process user CPU Sampled family RSS of functions runs

main 73.1 s 74.1 s 136.7 s 5740 MiB

this PR 45.9 s 47.2 s 219.7 s 4474 MiB

On main's base, REA still runs two concurrent inventories (the session's and the export's; #4062 removes the duplicate), so CPU goes up here while wall time falls. Both PRs together should give one inventory at about 23 s. That is not measured as a combination. Sampled RSS under memory pressure is not a reliable comparison, and I make no memory claim. Response bytes are unchanged (3413); model tokens were not measured.
Remaining proof gaps: no Linux run; the default path is unchanged and covered by the real lane at jobs=1 only.
Observed, derived, and inferred claims remain distinguishable.
Artifact identity, source provenance, and failed attempts remain preserved.
Unsupported, incomplete, unavailable, or uncertain outcomes remain visible.

Build	`search_procedures`	Process wall	Process user CPU	Sampled family RSS of `functions` runs
main	73.1 s	74.1 s	136.7 s	5740 MiB
this PR	45.9 s	47.2 s	219.7 s	4474 MiB

Validation performed

npm run test:focused -- tests/boundary/providers/kuna/*.test.ts: 94 passed (11 files), three consecutive runs.
Changed tests on the base revision: 2 failed.
npm run check:fast: typecheck and lint passed.
npm run docs:check: passed.
REA_KUNA_COMMAND=… npm run verify:kuna (real Kuna 1.833, darwin/arm64, default jobs): passed, process lineage verified, cleanup: "complete".
Real Telegram measurements above; --jobs 1 vs no flag on zip: byte-identical.

Compatibility, safety, and release

Breaking changes or migration steps: none. Behavior changes only when REA_KUNA_JOBS > 1.
Real Hopper/Ghidra, browser, or OS coverage: real Kuna on macOS arm64 only.
Package or release metadata impact: none.
Security, privacy, process, or containment review: same owned process. More decode lanes only when the caller configures them.

Author readiness

Human owner:

I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work.
I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps.
I declare this PR ready for initial maintainer review.

Before merge

This PR addresses a concrete problem or an agreed enhancement.
Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff.
The PR has one focused outcome and the title follows type(scope): outcome.
Related issue is linked, or the reason for not linking one is stated above.
Tests cover changed observable behavior and meaningful failure paths.
Owning docs, contracts, and generated metadata are updated where needed.
User-visible CLI/MCP changes include representative output.
I checked the final diff for secrets, unrelated cleanup, and unsupported claims.

🤖 Generated with Claude Code

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/4066 **Author:** [@kaoru0822-kitauji](https://github.com/kaoru0822-kitauji) **Created:** 10/15/2026 **Status:** ❌ Closed **Base:** `main` ← **Head:** `fix/kuna-inventory-honors-jobs` --- ### 📝 Commits (1) - [`225d664`](https://github.com/morluto/rea/commit/225d664e49cb3b4e99ec18b6fb09ec9b3cd0d996) fix(kuna): run the inventory with the configured decode lanes ### 📊 Changes **6 files changed** (+53 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `docs/kuna-provider.md` (+8 -8) 📝 `src/kuna/KunaCommand.ts` (+10 -0) 📝 `src/kuna/KunaProjectExport.ts` (+2 -1) 📝 `src/kuna/KunaSessionClient.ts` (+5 -1) 📝 `tests/boundary/providers/kuna/kunaProjectCache.test.ts` (+7 -1) 📝 `tests/boundary/providers/kuna/kunaProvider.test.ts` (+21 -0) </details> ### 📄 Description ## Summary `REA_KUNA_JOBS` reached only `kuna decompile-project`. The export's first step, the `kuna functions --json` inventory that every cold request waits for (listings, lookups, and name or address resolution before a single-function decompile), always ran serially, and so did the session's own inventory run. Kuna documents `functions --jobs N` as returning "the serial one byte for byte" inventory from N decode lanes. Raising `REA_KUNA_JOBS` therefore left the slowest blocking step untouched. Refs #1957. ## Problem and expected behavior Smallest trigger: `REA_KUNA_JOBS=8`, cold cache, any first request on a large image. Observed: `kuna functions <copy> --json` without `--jobs`, at 66 s for a 254 MB Mach-O. Expected: the inventory uses the configured decode lanes, because its output cannot change. ## Change and scope - New `kunaInventoryArguments(input, jobs)` in `KunaCommand.ts` builds the one `kuna functions … --json --jobs N` command line. The export's inventory step and the session's own inventory run both use it, so the command is no longer written out twice. - `docs/kuna-provider.md`: the `REA_KUNA_JOBS` row says it applies to both commands and that the inventory is identical for any value. - Default unchanged: `REA_KUNA_JOBS` stays 1, and `--jobs 1` produced a byte-identical inventory on `zip` (`cmp`). Not included: no new setting and no change to the default. Parallel lanes raised the inventory's peak RSS on Telegram (6413 MiB with 8 lanes vs 3889 MiB serially, measured outside REA), so lanes stay opt-in through the existing setting. The cache key already includes `jobs`. #4062 (export inventory sharing) is independent; together, a cold first request runs one inventory with the configured lanes. Scope: an ordinary fix within the existing Kuna provider boundary; no maintainer scope decision applies. ## Contract and boundary impact - Semantic owner and earliest changed stage: `KunaCommand.kunaInventoryArguments`, used by `exportKunaProject` and `KunaSessionClient`. - Contribution scope fit and linked maintainer decision: not applicable. - CLI and MCP/tool-catalog contract: unchanged. Same inventory content. - Provider, bridge, target-format, or platform compatibility: Kuna only. `--jobs` is a `kuna functions` option in the verified 1.833. - Evidence, artifact, provenance, or reconstruction contract: unchanged. The inventory is identical, and the export key already includes `jobs`. - Target selection, authority, upstream behavior, and cleanup details: the same owned process, with more decode lanes inside it when configured. - Generated metadata, package, or installation impact: none. Expected effects: - [x] Read existing files or captured data. - [x] Launch or attach to a process. - [ ] Inject instrumentation or run scripts/code. - [ ] Change process memory, registers, files, or configuration. - [ ] Contact network services. - [ ] Recover protected code or work around protections. - [ ] Documentation or usability only; no target interaction. - [ ] Not sure yet; investigation or maintainer guidance needed. (Existing `kuna functions` runs gain `--jobs`.) ## Evidence and regression coverage - Tests added or updated: `kunaProvider.test.ts` gets "runs every inventory with the configured decode lanes": with `REA_KUNA_JOBS=4`, every `functions` call ends with `--json --jobs 4` and the export with `--jobs 4`. `kunaProjectCache.test.ts` now expects `--jobs 1` on the export's inventory at the default. - Base reproduction: both tests fail on the base revision (`git stash` of `src/kuna`). - Kuna's equivalence claim, checked directly on `/Applications/Telegram.app/Contents/MacOS/Telegram` (thin arm64, 254 MB, 696,944 entries) with Kuna 1.833, outside REA: | `kuna functions --json` | Wall | User CPU | Peak RSS | `functions` equal to serial | | --- | --- | --- | --- | --- | | serial | 65.7 s | 61.9 s | 3889 MiB | — | | `--jobs 4` | 30.2 s | 84.5 s | 6765 MiB | yes | | `--jobs 8` | 23.4 s | 105.7 s | 6413 MiB | yes | | `--jobs auto` (10 lanes) | 23.0 s | 107.5 s | 6679 MiB | yes | - Through REA, MCP cold `search_procedures` on the same binary with `REA_KUNA_JOBS=8`, one run per build: | Build | `search_procedures` | Process wall | Process user CPU | Sampled family RSS of `functions` runs | | --- | --- | --- | --- | --- | | main | 73.1 s | 74.1 s | 136.7 s | 5740 MiB | | this PR | 45.9 s | 47.2 s | 219.7 s | 4474 MiB | On main's base, REA still runs two concurrent inventories (the session's and the export's; #4062 removes the duplicate), so CPU goes up here while wall time falls. Both PRs together should give one inventory at about 23 s. That is not measured as a combination. Sampled RSS under memory pressure is not a reliable comparison, and I make no memory claim. Response bytes are unchanged (3413); model tokens were not measured. - Remaining proof gaps: no Linux run; the default path is unchanged and covered by the real lane at `jobs=1` only. - [x] Observed, derived, and inferred claims remain distinguishable. - [x] Artifact identity, source provenance, and failed attempts remain preserved. - [x] Unsupported, incomplete, unavailable, or uncertain outcomes remain visible. ## Validation performed - `npm run test:focused -- tests/boundary/providers/kuna/*.test.ts`: 94 passed (11 files), three consecutive runs. - Changed tests on the base revision: 2 failed. - `npm run check:fast`: typecheck and lint passed. - `npm run docs:check`: passed. - `REA_KUNA_COMMAND=… npm run verify:kuna` (real Kuna 1.833, darwin/arm64, default jobs): passed, process lineage verified, `cleanup: "complete"`. - Real Telegram measurements above; `--jobs 1` vs no flag on `zip`: byte-identical. ## Compatibility, safety, and release - Breaking changes or migration steps: none. Behavior changes only when `REA_KUNA_JOBS` > 1. - Real Hopper/Ghidra, browser, or OS coverage: real Kuna on macOS arm64 only. - Package or release metadata impact: none. - Security, privacy, process, or containment review: same owned process. More decode lanes only when the caller configures them. ## Author readiness Human owner:  - [ ] I reviewed the final diff and relevant existing code, understand the change and its edge cases, and take responsibility for the complete PR, including AI-assisted work. - [ ] I checked the evidence above, confirmed it supports the current change, and recorded meaningful validation gaps. - [ ] I declare this PR ready for initial maintainer review. ## Before merge - [ ] This PR addresses a concrete problem or an agreed enhancement. - [ ] Material scope and authority questions are resolved, and any required maintainer scope decision covers the final diff. - [ ] The PR has one focused outcome and the title follows `type(scope): outcome`. - [ ] Related issue is linked, or the reason for not linking one is stated above. - [ ] Tests cover changed observable behavior and meaningful failure paths. - [ ] Owning docs, contracts, and generated metadata are updated where needed. - [ ] User-visible CLI/MCP changes include representative output. - [ ] I checked the final diff for secrets, unrelated cleanup, and unsupported claims. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:11:20 +00:00

closed this issue
added the
pull-request
label

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

No description provided.

Rows
Columns