[GH-ISSUE #6198] [Feature] Page retained web-bundle endpoint observations and inferences after #6019 #3776

Closed
opened 2026-10-31 00:43:56 +00:00 by bsakaguchi · 0 comments
Owner

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

Before submitting

  • I searched open and closed issues and PRs for related proposals.
  • I reviewed the contribution scope; this proposal still needs maintainer triage.
  • This request contains no credentials, private samples, or sensitive target data.

Area

Evidence, artifacts, or reconstruction

Current limitation

Analyst question: Which endpoint observations and endpoint-candidate inferences are retained in this completed web-bundle analysis, and where did each come from? I want a bounded page without returning every script or repeating capture/analysis.

Source-derived on main 73be86c39e6c13139e0755c8ff2f8e95751d4a72: analyze_web_bundle produces retained Evidence, but the current analysis-view dispatch does not support that parent. Open PR #6019 adds web-bundle summaries and queryable JavaScript route inventories. Its inspected head 638a63486d6b48a8aeba2f3530c188ec42d7bca8 exposes javascript-routes; it does not yet provide general pages of the bundle's existing endpoint observations and inference records.

This is a proposed follow-up to #6019, not a request for another summary/route implementation. Re-evaluate the remaining gap after that PR lands; if its final scope covers this request, close this issue as covered.

Desired outcome and success criteria

  • Read a caller-selected retained web-bundle Evidence ID and page its existing endpoint observations and inference records as distinct collections.
  • Preserve exact parent identity, source/script identity and locations, original record order, duplicate values at different locations, and producer coverage/limitations. An endpoint_candidate remains an inference, not a confirmed request or backend capability.
  • Report the selected collection's page bounds/counts. Exhausting pages must not upgrade partial source capture or analysis to complete.
  • Reuse completed Evidence without recapturing the target, fetching assets, or rerunning JavaScript analysis.
  • Preserve complete export as a fallback, including when a single retained record cannot fit the selected transport budget. Do not silently truncate a record and describe it as complete.

Expected interaction with targets

Read existing files or captured data. The requested projection does not require live attachment, target code execution, injection, target mutation, or network retrieval. Any view-Evidence retention should follow the existing analysis-view semantics.

Target and scope details

Extend the retained-view infrastructure that #6019 establishes if maintainers agree. This request does not add route discovery, infer new endpoints, compare endpoints with traffic, import private captures, or restore inaccessible server-side code.

Verification available so far

I can suggest a sample or manual check. The current limitation is source-derived; no implementation or performance improvement is claimed.

Suggested regression fixture: one script with fetch('/api/users'), a second distinct source location with the same literal, an unresolved client call retained as a candidate, and explicit partial source coverage. Page the stored observations and inferences separately; concatenated pages should match the selected original records exactly, preserve both duplicate locations, and retain the partial coverage. Also check empty pages, exact parent selection, unavailable retained Evidence, and individually oversized records. Run through CLI and MCP after implementation.

Alternatives considered

Exporting the complete retained bundle and filtering locally works today. It requires a separate local parsing step and a larger handoff than a selected view. No token, elapsed-time, or memory savings have been measured; those would need equivalent completed-workflow measurements.

Using #6019's route views addresses route questions, not arbitrary endpoint/inference records. Existing JavaScript-application views have a different parent/data model and do not establish that these web-bundle collections can be queried.

References

Prepared with AI assistance; this is a focused feature proposal, not a completed implementation or a transport-failure report.

Originally created by @hoffieyang on GitHub (Oct 22, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6198 ### Before submitting - [x] I searched open and closed issues and PRs for related proposals. - [x] I reviewed the contribution scope; this proposal still needs maintainer triage. - [x] This request contains no credentials, private samples, or sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Current limitation Analyst question: **Which endpoint observations and endpoint-candidate inferences are retained in this completed web-bundle analysis, and where did each come from?** I want a bounded page without returning every script or repeating capture/analysis. Source-derived on main `73be86c39e6c13139e0755c8ff2f8e95751d4a72`: `analyze_web_bundle` produces retained Evidence, but the current analysis-view dispatch does not support that parent. Open PR #6019 adds web-bundle summaries and queryable JavaScript route inventories. Its inspected head `638a63486d6b48a8aeba2f3530c188ec42d7bca8` exposes `javascript-routes`; it does not yet provide general pages of the bundle's existing endpoint observations and inference records. This is a proposed **follow-up to #6019**, not a request for another summary/route implementation. Re-evaluate the remaining gap after that PR lands; if its final scope covers this request, close this issue as covered. ### Desired outcome and success criteria - Read a caller-selected retained web-bundle Evidence ID and page its existing endpoint observations and inference records as distinct collections. - Preserve exact parent identity, source/script identity and locations, original record order, duplicate values at different locations, and producer coverage/limitations. An `endpoint_candidate` remains an inference, not a confirmed request or backend capability. - Report the selected collection's page bounds/counts. Exhausting pages must not upgrade partial source capture or analysis to complete. - Reuse completed Evidence without recapturing the target, fetching assets, or rerunning JavaScript analysis. - Preserve complete export as a fallback, including when a single retained record cannot fit the selected transport budget. Do not silently truncate a record and describe it as complete. ### Expected interaction with targets Read existing files or captured data. The requested projection does not require live attachment, target code execution, injection, target mutation, or network retrieval. Any view-Evidence retention should follow the existing analysis-view semantics. ### Target and scope details Extend the retained-view infrastructure that #6019 establishes if maintainers agree. This request does not add route discovery, infer new endpoints, compare endpoints with traffic, import private captures, or restore inaccessible server-side code. ### Verification available so far I can suggest a sample or manual check. The current limitation is source-derived; no implementation or performance improvement is claimed. Suggested regression fixture: one script with `fetch('/api/users')`, a second distinct source location with the same literal, an unresolved client call retained as a candidate, and explicit partial source coverage. Page the stored observations and inferences separately; concatenated pages should match the selected original records exactly, preserve both duplicate locations, and retain the partial coverage. Also check empty pages, exact parent selection, unavailable retained Evidence, and individually oversized records. Run through CLI and MCP after implementation. ### Alternatives considered Exporting the complete retained bundle and filtering locally works today. It requires a separate local parsing step and a larger handoff than a selected view. No token, elapsed-time, or memory savings have been measured; those would need equivalent completed-workflow measurements. Using #6019's route views addresses route questions, not arbitrary endpoint/inference records. Existing JavaScript-application views have a different parent/data model and do not establish that these web-bundle collections can be queried. ### References - #6019 — prerequisite/overlapping infrastructure; coordinate with its final API. - #3591 — related endpoint-versus-HAR comparison request. This proposal only reads facts already retained in one web bundle and does not implement comparison or claim runtime coverage. - [Current analysis-view owner](https://github.com/morluto/rea/blob/73be86c39e6c13139e0755c8ff2f8e95751d4a72/src/domain/analysisView/analysisView.ts). - [Inspected #6019 view contract](https://github.com/morluto/rea/blob/638a63486d6b48a8aeba2f3530c188ec42d7bca8/src/contracts/analysisViewToolContracts.ts). Prepared with AI assistance; this is a focused feature proposal, not a completed implementation or a transport-failure report.
Sign in to join this conversation.
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#3776
No description provided.