[GH-ISSUE #7282] [Feature] managed-members: filter rows by declaring type or name and project columns #4321

New issue

Closed

opened 2026-10-31 00:48:54 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:48:54 +00:00

Owner

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

Before submitting

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

Area

MCP or agent integration

Current limitation

inspect_analysis_view with kind: "managed-members" accepts only kind, collection, offset and limit (dist/domain/analysisView/managedMemberView.js, z.strictObject). There is no way to ask for one declaring type, one member name, or a subset of columns.

That is fine for a small assembly and painful for a large one. On a carved inner assembly (ScriptGraphicHelper, 3.1.0.0, MVID 1ed6b7e9-f60a-40e9-be7b-9e47be1d6e8a: 210 TypeDef, 2515 MethodDef, 1723 MemberRef) a single page of collection: "methods", offset: 1596, limit: 24 came back at roughly 50 KB. Each method row carries the full body.anchors list, and the largest method on that page alone has 1420 IL bytes / 757 decoded instructions. Finding one method meant paging through those rows, and transferred bytes rather than analysis became the limit.

The sibling views already have what is missing here, which is why the asymmetry is surprising rather than intentional-looking:

il2cpp-metadata accepts declaring_types / method_indices (il2cppMetadataView.js).
native-inventory accepts fields for column selection.

Use cases

Locating a single method or property by name inside a 2000+ method assembly (for example a version-check routine reached only through a view-model type), and reading one type's members without pulling the whole assembly through the view. Any UI framework assembly with hundreds of generated members shows the same shape.

Desired outcome and success criteria

Exact filters on managed-members, symmetric with the views above: names (member names) and/or declaring_types, plus an optional fields projection. Failing both, a way to omit the dominant array — for example include_anchors: false on methods rows.

Success: on the assembly above, {kind: "managed-members", collection: "methods", declaring_types: ["ScriptGraphicHelper.Base.VersionInfo"]} returns that type's methods in one small page, without anchors, instead of 24 arbitrary rows of roughly 50 KB.

Expected interaction with targets

Read existing files or captured data

Target and scope details (optional)

Observed on the retained Evidence of an already-carved .NET assembly (inspect_managed_artifact / inspect_managed_members). No new provider, no execution, no extraction is implied by the request.

Adjacent but distinct: the outer target is a .NET single-file bundle, which issue #2352 / PR #3787 already cover; this request is only about paging the retained member Evidence afterwards.

Verification available so far

I have a prototype or observed results

Verification details (optional)

Observed on rea-agents 6.8.0 (npm latest at the time), Node 24.22.1, Windows 11. Assembly SHA-256 852368c9b6fa9cbcba18b9464f9b89a7dab59ce3ae9189356c85d4fda26025fd, 8,666,112 bytes, carved from a 38,600,977 byte single-file bundle at file offset 0x14b2000.

Request: {"kind":"managed-members","collection":"methods","offset":1596,"limit":24} — 24 rows, about 50 KB of JSON, of which the body.anchors arrays dominate.

Alternatives considered

A hand-written ECMA-335 metadata and IL reader, which is what I ended up using: it found the target method in one pass and cost less than paging the view. Running inspect_managed_members once per type instead also narrows the result, but re-inspecting a large assembly to answer each question is more expensive than filtering retained rows.

Possible direction

Add names / declaring_types to managedMembersViewRequestSchema and apply them to the retained rows before paging, matching the il2cpp-metadata behaviour; add fields selection as native-inventory does. Anchors could stay opt-in per page. Proposal only.

References

Minor, same view: the inspect_analysis_view description reads "managed-members pages use collection types/exported_types/fields/methods/member_refs/call_edges/field_accesses/user_strings". fields there is a collection name, but it reads like the fields argument that other views accept, so I passed fields: [...] and got ["view","fields"] unknown_argument. Not a defect — rejecting unknown keys is correct — but writing it as collection: "fields" would remove the trap.

il2cppMetadataView.js (declaring_types), nativeInventoryView (fields projection), managedMemberView.js (current strict four-key schema).

Originally created by @379061296 on GitHub (Oct 26, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/7282 ### Before submitting - [x] I searched the open and closed issues and pull requests for a related proposal. - [x] I understand the [contribution scope](https://github.com/morluto/rea/blob/main/CONTRIBUTING.md#contribution-scope) must be reviewed before integration; open questions are welcome here. - [x] This request does not include credentials, private samples, or sensitive target data. ### Area MCP or agent integration ### Current limitation `inspect_analysis_view` with `kind: "managed-members"` accepts only `kind`, `collection`, `offset` and `limit` (`dist/domain/analysisView/managedMemberView.js`, `z.strictObject`). There is no way to ask for one declaring type, one member name, or a subset of columns. That is fine for a small assembly and painful for a large one. On a carved inner assembly (`ScriptGraphicHelper`, 3.1.0.0, MVID `1ed6b7e9-f60a-40e9-be7b-9e47be1d6e8a`: 210 `TypeDef`, 2515 `MethodDef`, 1723 `MemberRef`) a single page of `collection: "methods", offset: 1596, limit: 24` came back at roughly 50 KB. Each method row carries the full `body.anchors` list, and the largest method on that page alone has 1420 IL bytes / 757 decoded instructions. Finding one method meant paging through those rows, and transferred bytes rather than analysis became the limit. The sibling views already have what is missing here, which is why the asymmetry is surprising rather than intentional-looking: - `il2cpp-metadata` accepts `declaring_types` / `method_indices` (`il2cppMetadataView.js`). - `native-inventory` accepts `fields` for column selection. ### Use cases Locating a single method or property by name inside a 2000+ method assembly (for example a version-check routine reached only through a view-model type), and reading one type's members without pulling the whole assembly through the view. Any UI framework assembly with hundreds of generated members shows the same shape. ### Desired outcome and success criteria Exact filters on `managed-members`, symmetric with the views above: `names` (member names) and/or `declaring_types`, plus an optional `fields` projection. Failing both, a way to omit the dominant array — for example `include_anchors: false` on `methods` rows. Success: on the assembly above, `{kind: "managed-members", collection: "methods", declaring_types: ["ScriptGraphicHelper.Base.VersionInfo"]}` returns that type's methods in one small page, without anchors, instead of 24 arbitrary rows of roughly 50 KB. ### Expected interaction with targets - Read existing files or captured data ### Target and scope details (optional) Observed on the retained Evidence of an already-carved `.NET` assembly (`inspect_managed_artifact` / `inspect_managed_members`). No new provider, no execution, no extraction is implied by the request. Adjacent but distinct: the outer target is a .NET single-file bundle, which issue #2352 / PR #3787 already cover; this request is only about paging the retained member Evidence afterwards. ### Verification available so far I have a prototype or observed results ### Verification details (optional) Observed on rea-agents 6.8.0 (npm latest at the time), Node 24.22.1, Windows 11. Assembly SHA-256 `852368c9b6fa9cbcba18b9464f9b89a7dab59ce3ae9189356c85d4fda26025fd`, 8,666,112 bytes, carved from a 38,600,977 byte single-file bundle at file offset `0x14b2000`. Request: `{"kind":"managed-members","collection":"methods","offset":1596,"limit":24}` — 24 rows, about 50 KB of JSON, of which the `body.anchors` arrays dominate. ### Alternatives considered A hand-written ECMA-335 metadata and IL reader, which is what I ended up using: it found the target method in one pass and cost less than paging the view. Running `inspect_managed_members` once per type instead also narrows the result, but re-inspecting a large assembly to answer each question is more expensive than filtering retained rows. ### Possible direction Add `names` / `declaring_types` to `managedMembersViewRequestSchema` and apply them to the retained rows before paging, matching the `il2cpp-metadata` behaviour; add `fields` selection as `native-inventory` does. Anchors could stay opt-in per page. Proposal only. ### References Minor, same view: the `inspect_analysis_view` description reads "managed-members pages use collection types/exported_types/**fields**/methods/member_refs/call_edges/field_accesses/user_strings". `fields` there is a collection name, but it reads like the `fields` argument that other views accept, so I passed `fields: [...]` and got `["view","fields"] unknown_argument`. Not a defect — rejecting unknown keys is correct — but writing it as `collection: "fields"` would remove the trap. `il2cppMetadataView.js` (`declaring_types`), `nativeInventoryView` (`fields` projection), `managedMemberView.js` (current strict four-key schema).

bsakaguchi closed this issue

2026-10-31 00:48:54 +00:00

bsakaguchi referenced this issue

2026-10-31 00:51:42 +00:00

[GH-ISSUE #7774] [Design] Bound per-binding member-write records in JavaScript semantic analysis #4639

bsakaguchi referenced this issue

2026-10-31 01:12:24 +00:00

[PR #4321] [CLOSED] perf(javascript): index member effects only for resolvable request targets #6170

bsakaguchi referenced this issue

2026-10-31 01:12:28 +00:00

[PR #4331] [CLOSED] perf(javascript): select member-mutation origins after coverage #6178

bsakaguchi referenced this issue