[GH-ISSUE #8866] [Design] Select recorded references by source address #7779

New issue

Open

opened 2026-11-04 05:58:17 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-04 05:58:17 +00:00

Owner

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

Before submitting

I searched open and closed issues and pull requests for related work.
I understand the contribution scope must be reviewed before integration.
This report contains no credentials or private targets.

Decision needed

Should an agent be able to select recorded reference rows by an exact source address without downloading or scanning every page, or is the existing local-file/script workflow sufficient?

Context and evidence

In the unmerged #8863 prototype on top of #8851 and #8444, real Kuna 1.990 on macOS arm64 returned 40,000 stored pointer rows for an owned static Mach-O fixture. The raw-array view supports offset and limit, not selection by address; a caller who does not know the matching row's offset must inspect pages or export the parent. One 1,000-row CLI view page was 49,645 o200k_base tokens including its envelope. This is one controlled fixture, not a prevalence or autonomous-agent measurement.

With the already-written full CLI JSON, a local jq exact-match query returned the one requested source-address row (51 tokens of JSON) in 0.06 s elapsed with approximately 40 MiB maximum RSS on this host. That timing excludes analysis, generating or reading the full result as agent context, and any agent/tool selection costs; it is not an equivalent end-to-end comparison. The target was not executed or modified.

The real forwarding-alias control also showed that raw Kuna pointer rows can target the requested address or an alias, while the normalized xrefs answer is restricted to the exact target. Any selection must retain that distinction and report source provenance and coverage.

Expected interaction with targets

Read existing files or captured data.

Options and tradeoffs

Compare the existing file/script route with an exact selection in an existing native or recorded view. Avoid assuming raw provider field names have provider-neutral semantics, and account for repeated scans, schemas, context, and retained Evidence. Whether MCP-only callers need a new selection capability is unverified.

Verification available so far

I have a prototype or observed results.

Success criteria and open questions

Measure a representative analyst task including schema, calls, rows, time and memory, using exact and alias-target controls. Preserve unknowns and distinguish no matching recorded row from complete reference coverage. Compare a real agent trace if agent discoverability is claimed.

References

#8510, #8590, #8851, #8863.

cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 4, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8866 ### Before submitting - [x] I searched open and closed issues and pull requests for related work. - [x] I understand the contribution scope must be reviewed before integration. - [x] This report contains no credentials or private targets. ### Decision needed Should an agent be able to select recorded reference rows by an exact source address without downloading or scanning every page, or is the existing local-file/script workflow sufficient? ### Context and evidence In the unmerged #8863 prototype on top of #8851 and #8444, real Kuna 1.990 on macOS arm64 returned 40,000 stored pointer rows for an owned static Mach-O fixture. The raw-array view supports offset and limit, not selection by address; a caller who does not know the matching row's offset must inspect pages or export the parent. One 1,000-row CLI view page was 49,645 `o200k_base` tokens including its envelope. This is one controlled fixture, not a prevalence or autonomous-agent measurement. With the already-written full CLI JSON, a local `jq` exact-match query returned the one requested source-address row (51 tokens of JSON) in 0.06 s elapsed with approximately 40 MiB maximum RSS on this host. That timing excludes analysis, generating or reading the full result as agent context, and any agent/tool selection costs; it is not an equivalent end-to-end comparison. The target was not executed or modified. The real forwarding-alias control also showed that raw Kuna pointer rows can target the requested address or an alias, while the normalized `xrefs` answer is restricted to the exact target. Any selection must retain that distinction and report source provenance and coverage. ### Expected interaction with targets Read existing files or captured data. ### Options and tradeoffs Compare the existing file/script route with an exact selection in an existing native or recorded view. Avoid assuming raw provider field names have provider-neutral semantics, and account for repeated scans, schemas, context, and retained Evidence. Whether MCP-only callers need a new selection capability is unverified. ### Verification available so far I have a prototype or observed results. ### Success criteria and open questions Measure a representative analyst task including schema, calls, rows, time and memory, using exact and alias-target controls. Preserve unknowns and distinguish no matching recorded row from complete reference coverage. Compare a real agent trace if agent discoverability is claimed. ### References #8510, #8590, #8851, #8863. cc @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

enhancement

triage

labels

2026-11-04 05:58:17 +00:00

bsakaguchi referenced this issue

2026-11-04 11:18:35 +00:00

[PR #7062] [CLOSED] test(cli): preserve literal heading regression coverage #7615