[GH-ISSUE #721] [Design] Separate target cleanup from the lifetime of retained investigation Evidence #320

Closed
opened 2026-10-15 18:23:50 +00:00 by bsakaguchi · 0 comments
Owner

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

Before submitting

  • I searched the open and closed issues and relevant pull requests for a related report.
  • I removed credentials, tokens, private paths, and sensitive target data.

Decision needed

Should close_binary release target/provider resources while previously collected Evidence remains available to the connected investigation? If target close intentionally ends Evidence retention, what explicit lifetime and export behavior should callers receive?

Context and evidence

A fresh real MCP connection analyzed a JS directory, producing one retained record. Opening index.js kept that record. Export before close succeeded. Calling close_binary then left get_evidence_bundle with zero records, although the transport remained connected. The primary multi-domain connection also ended with an empty ledger after target cleanup.

This is current behavior, not proof of corruption. Previously returned inline results and already-exported files remain usable. #50 explicitly required clearing the owning session ledger on close, so changing this boundary needs a design decision rather than a bug label.

Boundary and invariants

Distinguish provider/target lifecycle, connection/investigation lifetime, and caller-selected durable exports. Keep memory bounded through explicit, truthful lifecycle rules; do not silently evict Evidence or automatically persist it to undisclosed locations.

Provider cleanup must remain prompt and ownership-scoped. References remain connection-scoped unless explicitly transferred. Preserve record identities/provenance and report actual retention effects. Do not add repeated confirmation booleans or mandatory save/prepare phases.

Options and tradeoffs

  1. Retain Evidence until the connected investigation ends, independently of target close. This supports follow-up reuse but requires documented memory accounting and explicit disposal semantics.
  2. Preserve target-close clearing, but make the consequence and supported export-before-close workflow obvious in tool/CLI contracts and output. Compatible, but cleanup still requires caller-managed export ordering.
  3. Define an additive caller-selected export-and-close composition using existing primitives if repeated usage justifies it. Verify all supported Evidence categories and atomic failure behavior; do not assume analysis snapshots already preserve all independent JS/process/browser records.

Success criteria and open questions

  • Reproduce analyze JS -> inspect bundle -> open index.js -> inspect bundle -> export -> close -> inspect bundle using public MCP calls.
  • Resolve and document the intended lifetime for Evidence from independent domains.
  • Closing provider resources neither leaks processes nor silently loses records contrary to the chosen contract.
  • Exported records remain usable and exact references have actionable expiration behavior.
  • CLI/MCP lifecycle documentation and representative user journeys agree.

Open questions: which object owns multi-target/multi-domain investigation results, and how should memory/resource limits behave without silent eviction?

References

Hands-on public CLI/MCP evaluation, findings F11. Baseline: REA 4.0.1, source revision c3bc38bf6c74d2175a4680530dcadd6cab0e7791; evaluation date 2026-10-06.

#50 specifies the existing clear-on-close behavior; #99 discusses resource retention. docs/mcp-contracts.md; README.md. The hands-on result is 1 record before/after open, 0 after close; snapshot coverage was not evaluated.

Originally created by @N0zoM1z0 on GitHub (Oct 6, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/721 ### Before submitting - [x] I searched the open and closed issues and relevant pull requests for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Decision needed Should close_binary release target/provider resources while previously collected Evidence remains available to the connected investigation? If target close intentionally ends Evidence retention, what explicit lifetime and export behavior should callers receive? ### Context and evidence A fresh real MCP connection analyzed a JS directory, producing one retained record. Opening index.js kept that record. Export before close succeeded. Calling close_binary then left get_evidence_bundle with zero records, although the transport remained connected. The primary multi-domain connection also ended with an empty ledger after target cleanup. This is current behavior, not proof of corruption. Previously returned inline results and already-exported files remain usable. [#50](https://github.com/morluto/rea/issues/50) explicitly required clearing the owning session ledger on close, so changing this boundary needs a design decision rather than a bug label. ### Boundary and invariants Distinguish provider/target lifecycle, connection/investigation lifetime, and caller-selected durable exports. Keep memory bounded through explicit, truthful lifecycle rules; do not silently evict Evidence or automatically persist it to undisclosed locations. Provider cleanup must remain prompt and ownership-scoped. References remain connection-scoped unless explicitly transferred. Preserve record identities/provenance and report actual retention effects. Do not add repeated confirmation booleans or mandatory save/prepare phases. ### Options and tradeoffs 1. Retain Evidence until the connected investigation ends, independently of target close. This supports follow-up reuse but requires documented memory accounting and explicit disposal semantics. 2. Preserve target-close clearing, but make the consequence and supported export-before-close workflow obvious in tool/CLI contracts and output. Compatible, but cleanup still requires caller-managed export ordering. 3. Define an additive caller-selected export-and-close composition using existing primitives if repeated usage justifies it. Verify all supported Evidence categories and atomic failure behavior; do not assume analysis snapshots already preserve all independent JS/process/browser records. ### Success criteria and open questions - Reproduce analyze JS -> inspect bundle -> open index.js -> inspect bundle -> export -> close -> inspect bundle using public MCP calls. - Resolve and document the intended lifetime for Evidence from independent domains. - Closing provider resources neither leaks processes nor silently loses records contrary to the chosen contract. - Exported records remain usable and exact references have actionable expiration behavior. - CLI/MCP lifecycle documentation and representative user journeys agree. Open questions: which object owns multi-target/multi-domain investigation results, and how should memory/resource limits behave without silent eviction? ### References Hands-on public CLI/MCP evaluation, findings F11. Baseline: REA 4.0.1, source revision [c3bc38bf6c74d2175a4680530dcadd6cab0e7791](https://github.com/morluto/rea/commit/c3bc38bf6c74d2175a4680530dcadd6cab0e7791); evaluation date 2026-10-06. [#50](https://github.com/morluto/rea/issues/50) specifies the existing clear-on-close behavior; [#99](https://github.com/morluto/rea/issues/99) discusses resource retention. [docs/mcp-contracts.md](https://github.com/morluto/rea/blob/c3bc38bf6c74d2175a4680530dcadd6cab0e7791/docs/mcp-contracts.md); [README.md](https://github.com/morluto/rea/blob/c3bc38bf6c74d2175a4680530dcadd6cab0e7791/README.md). The hands-on result is 1 record before/after open, 0 after close; snapshot coverage was not evaluated.
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#320
No description provided.